Standards Update (4 of 4): IEEE P1003
Moderator, John S. Quarterman
std-unix at longway.TIC.COM
Mon Jan 25 03:22:36 AEST 1988
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
More information about the Comp.std.unix
mailing list