Path: utzoo!attcan!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!mailrus!wuarchive!usc!cs.utexas.edu!longway!std-unix From: hlj@posix.COM (Hal Jespersen) Newsgroups: comp.std.unix Subject: Re: Standards Update, IEEE 1003.0: POSIX Guide Message-ID: <636@longway.TIC.COM> Date: 13 Apr 90 15:38:47 GMT References: <626@longway.TIC.COM> Sender: std-unix@longway.TIC.COM Reply-To: std-unix@uunet.uu.net Organization: POSIX Software Group, Redwood City, CA Lines: 69 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: hlj@posix.COM (Hal Jespersen) In article <626@longway.TIC.COM> From: > 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