Path: utzoo!mnetor!uunet!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update (1 0f 4): Overview
Message-ID: <112@longway.TIC.COM>
Date: 24 Jan 88 17:15:49 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 122
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
Standards Update
An update on UNIX and C Standards Activities
January 21, 1988
Written for the USENIX Association
by Shane P. McCarron, NAPS Inc.
[This report was written at the request of the Board of
Directors of the USENIX Association. In the interests of
reducing article sizes and making followups easier to
manage, I am posting it in four parts, divided according to
the following topics:
Overview
X3J11 and the X3.159 C Programming Language Standard
NBS FIPS
IEEE P1003 Subcommittees
-mod]
The Standards community isn't necessarily a closed entity,
but it is one that is hard to look into. There are so many
different activities going on all over the place that it is
difficult for the most people to get involved. I suppose
this is as it should be, since if everyone were involved,
nothing would ever get accomplished. However, it is always
good to know what is going on at a macro level, even if the
details pass you by.
That is where this report comes in - I am going to try and
summarize what has transpired in the Unix and C standards
areas during the previous three months. As anyone who has
been involved in a standards committee can tell you, not a
lot will happen in a quarter in any one committee, but over
several committees the cumulative effect can be daunting.
Before I start summarizing what went on in the last quarter
on 1987, I should define the scope of this report. I am not
going to try to touch on all of the technical discussions
that go on. These are often boring, and if you have that
level of interest, you should really be on the mailing list
for the group in question. Instead, I am going to give an
overview of some of the key issues that were raised and the
important milestones that were reached or passed.
In addition to the activity at the December meetings of
P1003, a few other things happened that are worth noting:
- P1003.1 Final Ballot
Overview, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 2 - USENIX Association
On November 15th the P1003.1 document went out for its
full use ballot. The balloting period was 30 days, and
closed around December 15th. When ballot resolution is
completed, the first full use standard from a 1003
group will have been ratified. This should be around
March, 1988.
- New P1003 Working Groups
There are three new working groups under the P1003
committee (.0, .5, and .6). Since I haven't talked
about all of these before, here is a list of all of the
POSIX working groups:
1003.0 - POSIX Guide
1003.1 - Systems Interface
1003.2 - Shell and Tools Interface
1003.3 - Verification and Testing
1003.4 - Real Time
1003.5 - Ada Binding for POSIX
1003.6 - Security
- IEEE Standards Board
At the December meeting of the IEEE Standards Board,
the Board approved the IEEE Technical Advisory Group
Procedures document. This was a major event in that it
allowed the first meeting of the United States TAG on
POSIX to take place "in wedlock".
- US Technical Advisory Group on POSIX
The first meeting of the US TAG on POSIX was held in
conjunction with the P1003 meetings in December. A TAG
is a group that exists in each International Standards
Organization (OSI) member country that is interested in
a particular ISO working group (in this case, WG15 of
Suncommittee 22). The TAG recommends to the ISO
standards body for that topic in that country what the
countries' position should be on the issue. In this
case the standards body is the IEEE, and the issue is
POSIX. In a future report, I hope to spend more time
talking about what it means to be in the International
Standards Organization, and how it effects POSIX.
Since it was the first meeting, the members present
elected a chair and secretary, and learned about what
it means to be a TAG. In addition to this, the TAG
established what the US position on POSIX should be.
Basically this boils down to "The US recommends that
Overview, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 3 - USENIX Association
POSIX be accepted as a Draft Proposed Standard, but any
changes made to the standard by IEEE P1003.1 should be
incorporated into the ISO document." It would be very
bad form not to recommend our own standard :-)
Overview, January 21, 1988 Shane P. McCarron, NAPS Inc.
Volume-Number: Volume 13, Number 2
Path: utzoo!mnetor!uunet!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update (3 of 4): NBS FIPS
Message-ID: <114@longway.TIC.COM>
Date: 24 Jan 88 17:20:46 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 270
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
Standards Update
An update on UNIX and C Standards Activities
January 21, 1988
Written for the USENIX Association
by Shane P. McCarron, NAPS Inc.
- NBS POSIX FIPS
One other item that is of concern to system
implementors and application developers alike is the
POSIX FIPS that is being announced by NBS this month.
This FIPS will be used by most federal agencies when
drafting Request for Proposals (RFPs) for many classes
of applications.
Just what is NBS going to require? Well, the NBS POSIX
FIPS is based on POSIX D12, the draft that went out to
the balloting group. The final POSIX standard may be
considerably different than this, but NBS has assured
the .1 working group that they will incorporate the
substantive changes in the standard into their FIPS
when the standard is complete.
So, if NBS is going to specify POSIX as the FIPS, what
are we worried about? Well, in order to increase
consensus and support as many existing implementations
as possible, POSIX has a lot of "options" in it. NBS
felt that these "options" made it difficult for
applications developers to write applications that used
the nice facilities of POSIX (they are right), so they
are requiring that many of these options be included in
a FIPS conforming implementation. For systems
implementors, this means that you had better include
all of these options if you want to sell to the federal
government. For applications developers, it means that
if your customer base is the federal government, you
can use these facilities without fear - they will be
there.
What are these options? Well, the following is an
excerpt from the NBS POSIX FIPS draft specification.
As an aside, it is important to note that many of these
so-called "options" are not really options at all, but
rather cases in which there was some ambiguity as to
how the system would function. I will indicate in the
following list some examples of real options and their
opposites for clarity.
NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 2 - USENIX Association
- The term appropriate privileges shall be
synonymous with the term super-user.
This is not really an option, but rather a
clarification being introduced by the NBS people.
The term "appropriate privileges" was introduced
into the standard to provide for secure
implementations of POSIX. By indicating that
certain facilities of POSIX require "appropriate
privilege", the door was left open for
implementations where processes could have subsets
of the power normally granted to a monolithic
"super-user". In fact, the above requirement is
incorrect. You could not simply replace the term
"appropriate privileges" with the term "super-
user" throughout the standard and have it make any
sense. However, we get the idea.
- A null pathname shall be considered invalid and
generate an error (2.10.3, lines 894 - 896).
- The use of the chown() function shall be
restricted to a process with super-user privileges
(2.10.4, lines 924 - 926).
This is an example of a real option in POSIX. If
the macro _POSIX_CHOWN_RESTRICTED is defined, it
means that only a process with "appropriate
privilege" can change to owner of a file. This is
in conflict with the current System V definition
of how chown works, btu is more in line with
trusted implementations. Users should not be able
to "give away" files.
- Only the super-user shall be allowed to link or
unlink directories (2.10.4, lines 938 - 939).
Another useful option. A portable application may
need to know whether it requires "approprite
privileges" to move directories around.
- The owner of a file may use the utime() function
to set file timestamps to arbitrary values
(2.10.4, lines 943 - 945).
- The implementation shall support a value of
{NGROUPS_MAX} greater than or equal to eight (8)
(2.9.2). An implementation may provide an option
for setting {NGROUPS_MAX} to a value other than
eight (8).
NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 3 - USENIX Association
The POSIX standard is still in the ballot
resolution process. When it went to ballot it
defined the BSD-style supplementary groups
feature. this says that there is a group-id
associated with a process, but that there may be
additional, supplementary groups also.
As of this writing, the definition has been
changed to a more flexible definition. There will
now be an array of group IDs associated with a
process. Although this change has not been
accepted by the full balloting group yet, I think
that it will be.
- The implementation shall support the setting of
the group-ID of a file (when it is created) to
that of its parent directory (2.10.4, lines 934 -
937). An implementation may provide a
programmable selectable means for setting the
group-ID of a file (when it is created) to the
effective group-ID of the creating process.
This is another example of a true option. Here
the FIPS is specifying the BSD method of creating
files. This method make a lot of sense in a
multiple group per process environment. However,
they also allow the System V behavior.
- The use of chown() shall be restricted to changing
the group-ID of a file to the effective group-ID
of a process or when {NGROUPS_MAX} > 0, to one of
its supplementary group-IDs (2.10.4, lines 927 -
930).
- The exec() type functions shall save the effective
user- ID and group-ID (2.10.3, lines 902 - 903).
This mirrors the System V behavior.
- The kill() function shall use the saved set user-
ID of the receiving process instead of the
effective user-ID to determine eligibility to send
the signal to a process (2.10.3, lines 891 - 893).
This is also similar to System V.
- When a session process group leader executes an
exit() a SIGHUP signal shall be sent to each
member of the session process group (2.10.3 lines
880 - 883).
NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 4 - USENIX Association
- The terminal special characters defined in
Sections 7.1.1.10 and 7.1.2.7 can be individually
disabled by using the value specified by
_POSIX_V_DISABLE (2.10.4, lines 946 - 949;
7.1.1.10; 7.1.2.7).
- The implementation shall support the
_POSIX_JOB_CONTROL option 2.10.3, lines 884 -
886).
Although I have not described how Job Control
works under POSIX, suffice it to say that it is
confusing at best. The ballot resolution group is
still trying to decide how to resolve the problems
pointed out during balloting.
- The implementation shall provide a single utility
for reading and writing POSIX data interchange
format files (10.). This utility shall be capable
of reading USTAR and CPIO data interchange formats
without requiring the format to be specified. The
implementation shall write CPIO data interchange
format when no option on format type is specified.
- Pathnames longer than {NAME_MAX} shall be
considered invalid and generate an error (2.10.4,
lines 940 - 942).
- When the rename(), unlink() or rmdir() function is
unsuccessful because the conditions for [EBUSY]
occur, the implementation shall report the [EBUSY]
errno (5.5.1.4, lines 481 - 482; 5.5.2.4, lines
523 - 524; 5.5.3.4, lines 593 - 594).
- When the rename() function is unsuccessful because
the conditions for [EXDEV] occur, the
implementation shall report the [EXDEV] errno
(5.5.3.4, lines 593 - 594).
- When the fork() or exec type function is
unsuccessful because the conditions for [ENOMEM]
occur, the implementation shall report the
[ENOMEM] errno (3.1.1.4, line 54; 3.1.2.4, lines
175 - 176).
- When the getcwd() function is unsuccessful because
the conditions for [EACCES] occur, the
implementation shall report the [EACCES] errno
(5.2.2.4, lines 148 - 149).
NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 5 - USENIX Association
- When the chown() or wait2() function is
unsuccessful because the conditions for [EINVAL]
occur, the implementation shall report the
[EINVAL] errno (3.2.1.4, line 272; 5.6.5.4, line
857).
- The implementation shall detect an [EFAULT] errno
condition (2.5, lines 554 - 558). The
implementation must state as part of the required
documentation; (1) the conditions when an [EFAULT]
is detected and an [EFAULT] errno is generated and
(2) those conditions, if any, when [EFAULT] may
not be detectable.
- The tcsetattr() function shall only set the
parameters supported by the underlying hardware
associated with the terminal (7.2.1.2, line 502).
- An interrupted write() function shall return a
count of the number of bytes successfully
transferred from the application program to the
system (6.4.2.2, lines 195 - 196; 6.4.2.4. lines
240 - 242).
- An implementation may provide errno [ENOEXIST] in
place of errno [EACCES].
- A POSIX FIPS implementation shall successfully
PASS the NBS-PCTS validation suite.
From all of these options, I am sure that it is obvious
that there is room for considerable variation in the
POSIX standard. The FIPS goes a long way towards
firming up an otherwise wishy-washy document. Since
many system implementors want to sell to the US
Government, it is probable that all of the above
requirements will be available on a majority of POSIX
conforming systems. This is excellent news for
application developers who want to take advantage of
some of the additional facilities introduced in POSIX
as optional.
NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc.
Volume-Number: Volume 13, Number 4
Path: utzoo!mnetor!uunet!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update (4 of 4): IEEE P1003
Message-ID: <115@longway.TIC.COM>
Date: 24 Jan 88 17:22:36 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 165
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
Standards Update
An update on UNIX and C Standards Activities
January 21, 1988
Written for the USENIX Association
by Shane P. McCarron, NAPS Inc.
Status of the IEEE P1003 Working Groups:
- 1003.1 - System Services Interface
The .1 working group has reached an interesting point
in its life. Since the standard they have produced is
now in final ballot and ballot resolution, the working
group in effect has nothing more to do. At the
December meeting they tried to decide what, if
anything, should be done by this body in the future.
Although no decision on this was made, many good
options were suggested.
Most promising among these is the design of a language
independent description of POSIX. One of the
requirements that ISO made of POSIX when it was adopted
as a Draft Proposed Standard last fall was that at some
point in the future it be described in such a way that
they functionality could be understood without an
understanding of the C language. ISO recognized that
it was unrealistic to make this a requirement before
adopting the standard, but felt that it was reasonably
important. I feel that this is something the working
group will be taking on soon after the Full Use
Standard is approved by IEEE.
- 1003.2 - Shell and Tools Interface
The Shell and Tools group is operating under a very
ambitious schedule. The National Bureau of Standards
(NBS) has indicated that they are going to declare a
Federal Information Processing Standard (FIPS) based on
the command set in the .2 standard, and that they are
going to do so in the summer of '88. This working
group only started serious work 1 year ago, and has
already produced a larger document than the .1 group
did in 4. The group is working hard to make sure that
the command set is locked down before the deadline
being imposed by NBS.
Unfortunately, this has the consequence that many
decisions are being made as rapidly as possible. I am
afraid that the resulting standard may be one that is
IEEE P1003, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 2 - USENIX Association
flawed, if only because the group is moving forward too
fast. On the other hand, the .1 group was guilty of
exactly the opposite, and NBS pressure has forced that
group to really get its act together. It has proven to
be a boon there, and it may do so here as well.
The Shell and Tools group has a milestone schedule
something like:
Date Milestone
Mar '88 Command Selection frozen;
75% described.
Jun '88 100% commands described;
functional freeze
Oct '88 Clean-up, slack; produce
"mock ballot" for draft (#8);
international signoff.
Jan '89 Resolve mock objections;
produce balloting draft (#9)
Apr '89 Resolve ballot objections;
produce final standard.
Jul '89 Final standard approved by IEEE
This may not appear to be all that hectic a pace, but I
can assure you that it is. When I say that the
commands are 100% described, it means that the current
functionality of each command that has been included in
the standard (a substantial part of the current "un*x"
command set) is described in painful detail. The goal
of the standard is to describe each command in such a
way that a person who has never seen a un*x machine can
write the commands from scratch. It's a lot of text.
With about 75% of the commands in, and those being
about 75% described (albeit incorrectly in some cases)
the document is now approaching 400 pages. In a future
report I will tell you just what is involved in a
command description. We don't have the space this time
:-)
- 1003.3 - Testing and Verification
This is another group that has been very active in the
last year or so. They have the dubious honor of
figuring out how to test that implementations of the .1
standard are actually conforming. Although the IEEE is
IEEE P1003, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 3 - USENIX Association
not going to be providing any validation services or
rating and systems, P1003 thought that it was important
that they define what parts of the system should be
tested in what ways.
The .3 group seems to be on track for balloting within
the next 6 to 9 months. There work is very far along,
and a verification suite is already being worked on by
the NBS based on the .3 assertion list about POSIX.
Although the .3 document will not be as earth-
shattering as POSIX, it is a still a very important
step - actually showing how to test conformance to a
standard at the same time you are defining one.
- 1003.4 - Real Time
Until recently, all the real time considerations in
POSIX were being looked into by a /usr/group technical
committee. Last fall that committee decided that their
research was mature enough that they could actually
start the work of producing a standard about it. The
real time work promises to add much of the
functionality that I and many others feel is absolutely
necessary in POSIX. Things like semaphores, shared
memory, and event processing. All of those inter-
process communication things that were left out of the
.1 standard because they just did not have the time.
Unfortunately, there is quite a bit of dissension as to
how all of these things should be implemented. Not
just IPC, but also contiguous files, timers, and those
things that a real time application would need to
really be real time. After talking to some of the
people who attended the December meeting, I would guess
that this group has a long way to go.
However, what will happen when they get there? At this
time I'm guessing that the .4 document will be
positioned as a supplement to the .1 standard. It
should require no changes to the .1 standard, and will
probably be a set of optional facilities, as job
control and some others are already. When this
standard is finally produced, it will answer many of
the objections we have heard to POSIX all along. I am
sure that it will be well received. Let's hope that it
can be timely enough to be useful.
IEEE P1003, January 21, 1988 Shane P. McCarron, NAPS Inc.
Volume-Number: Volume 13, Number 5
|