🚀 go-pugleaf

From: hlj@posix.COM (Hal Jespersen)

In article <626@longway.TIC.COM> From: <jsh@usenix.org>
>            An Update on UNIX* and C Standards Activities
>                             January 1990
>                 USENIX Standards Watchdog Committee
>                   Jeffrey S. Haemer, Report Editor
>IEEE 1003.0: POSIX Guide Update
> ...
>An argument made against the requirement is that it may damage
>implementations.  For example, real-time systems may lack even a file
>system, and may want a very limited subset of the POSIX interface to
>keep the implementation as small as possible.  If all of 1003.1 is
>required, vendors may have to add costly and unnecessary features just
>to claim POSIX compatibility.
>
>When the dust settles, I think 1003.1 will be strongly suggested but
>not required, because 1003.1 is a pretty arbitrary subset of any list
>of ``required system interfaces.''
>
>[Editor: We disagree.  1003.1 is a set of applications programming
>interfaces carefully chosen to be necessary and sufficient to make an
>operating system UNIX-like for the C programmer.  Providing standards
>for a UNIX-like operating system should be the goal of the POSIX
>standards, and attempts by vendors uncomfortable with UNIX to dilute
>the effort should be cut off at the pass.]
>
>[Author: POSIX must evolve a set of independent standards that have
>UNIX as their heritage. POSIX standards are all evolving as UNIX-like
>standards. Why discourage a vendor from implementing some subset of
>UNIX-like standards just because the vendor is not ready to provide a
>complete 1003.1 implementation? ]

As an aside to this discussion, the less-than-full-POSIX.1 approach
was the one we adopted for POSIX.2 [shell and utilities] back in 1986.
Although this decision has certainly made our job much more difficult
in terms of specifying exactly how the underlying system must work,
we felt that it was important to offer POSIX.2 comformance opportunities
to anyone with "enough" of UNIX to qualify.  For example, there should
be no reason a V7 system could not support POSIX.2 with a few mods;
these mods would definitely be less expensive than a fully-conforming
POSIX.1 system, with all the attendant documentation and conformance
testing required.

Now if you ask me whether I believe many non-POSIX.1 systems will be
supporting POSIX.2, I would have to say No.  The timing's wrong, as
most of the industry will support POSIX.1 anyway, and the ones that
don't probably aren't interested in the POSIX shell anyway.  But we
didn't know that when we started and we are reluctant to completely
shut the door on any enterprising vendors who may have other ideas.

					Hal Jespersen, Chair P1003.2
					POSIX Software Group
					447 Lakeview Way
					Redwood City, CA 94062
					Phone:	+1 (415) 364-3410
					FAX:	+1 (415) 364-4498
					UUCP:	uunet!posix!hlj
					 -or-	hlj@posix.COM

==========================================================================
The opinions expressed in this message are my own and do not necessarily
reflect those of the POSIX Working Groups or the IEEE.  To receive an
official interpretation concerning an approved IEEE standard, contact the
Secretary, IEEE Standards Board, P.O. Box 1331, 445 Hoes Lane, Piscataway,
NJ 08855-1331.
==========================================================================

Volume-Number: Volume 19, Number 66