From: n...@usenix.org (Nicholas M. Stoughton)
Subject: Standards Update, POSIX.1: System Services API
Date: 1996/02/22
Message-ID: <4giu38$3ct@cygnus.com>
X-Deja-AN: 140696528
sender: s...@cygnus.com
x-submissions: std-u...@uunet.uu.net
organization: USENIX Standards Report Editor
reply-to: std-u...@uunet.uu.net
newsgroups: comp.std.unix
Submitted-by: n...@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report Editor
Nicholas M. Stoughton < n...@usenix.org>, Report Editor
POSIX.1: System Services API
J Jay Meyer < j...@PO10.RV.unisys.com> reports on the January
14-19, 1996 meeting in Albuquerque, NM:
The POSIX.1a group met in Albuquerque with the other
Portable Applications Standards Committee (PASC) working
groups in January. The author of the past few snitch
reports has moved on to a new company and is no longer
attending. Thanks for your contributions Shravan! I'm the
chair of System Services and the chair of the POSIX.1a sub-
working group.
The ``hardest working group in PASC'' (or at least the
longest) met for 4 days, and though only now a small group
(peaking at about six people in the room), managed to make
substantial progress to getting the next draft out.
There was also a plenary meeting of the collective System
Services groups on Monday morning. We are not very
organized in this forum yet. Minutes from the previous
meeting were not distributed at all, which made them sort of
difficult to approve. There is not much time available for
lengthy discussions in this meeting, but we all briefly
introduced ourselves complete with a one-line weather report
from our home locale. We announced the passage of the
POSIX.1-1990 reaffirmation ballot, and discussed the fact
that we need to begin the process of revising the document.
ISO rules will require a revision in 1998. We can get
ourselves a Project Authorization Request (PAR) approved,
but we'll need a ballot coordinator, tech ed, and the rest
of the volunteer organization to pull this off. The
revision will afford an opportunity to smooth out any
wrinkles between the various amendments. We should also be
considering any issues that are global to the entire suite.
Candidate problem spaces include considering one header per
function, and doing ``something'' to enhance the returned
error information. Examples are that the ``read'' function
does not return enough information to even be able to say
that an application read to the end of file. We could also
provide alternate interfaces of some kind that don't return
an error status in a static variable.
The POSIX.1a group went through all of the long laundry list
of issues that our technical editor brought to the meeting.
We went through all of these items thoroughly
-- until the editor was happy that she knew what to do and
why. On several occasions, by rereading and reviewing areas
- 2 -
near where a balloter had objected, we found problems that
needed to be addressed even though there were no objections
to the particular problem.
One of these rather embarrassing uncovered ``problems'' was
that we were removing common-usage C from the document, but
did not get it all. Equally bad, or worse, is that this
important point did not show up in our PAR. We worked out
another revision to the PAR. The roots of this omission go
back to Language Independent days, where we were going to
have a binding to only ANSI C. By default, we'd then remove
common C.
One of our issues still being resolved is what ``fflush'' of
a seekable input device ought to mean.
I think that the recent abolition of formalized ballot slots
has been a positive influence on the group. There was some
initial concern that the removal of deadlines would push the
production of the document into the indeterminate future,
but the group was much more focused and deliberate, and less
``jittery'' over deadline concerns.
Since I'm writing this report so long after the fact (it's
been a month already!), I have the chance to add a
postscript. There have been some questions asked about the
POSIX.1d Realtime Extensions and POSIX.1j Advanced Realtime
Extensions documents. It turned out that POSIX.1j was being
held up because of a misunderstanding that there were still
ballot slots, and who had the responsibility to get it sent
in. This was done, and the document has been distributed by
the IEEE with a ballot slot ending March 28. POSIX.1d is in
the works, and we will make sure that its ballot does not
overlap with POSIX.1j.
Volume-Number: Volume 35, Number 83
|