🚀 go-pugleaf

Submitted-by: stephe@usenix.org (Stephen R. Walli)

Rick Greer <rick@ivy.isc.com> reports on the October 19-23, 1992
meeting in Utrecht, NL:

The big news in the POSIX.14 working group is that we have inherited
the POSIX.18 draft from Donn Terry and are now responsible for seeing
it through balloting.  POSIX.18 is the Platform Environment Profile,
more commonly known as a profile to describe the traditional
multi-user Unix platform.

Having been assured that the POSIX.18 document was ``practically ready
for balloting,'' we traded POSIX.14's March 1993 balloting slot to
POSIX.18. Remember that this year there are so many documents in
ballot that a strict timetable is being used to control the potential
administrative overload.  Our document's ballot slot had been
allocated as a purely defensive measure anyway - see below.  We also
decided to keep the balloting group open right up to the last minute,
so those interested in paying $25.00 for the privilege of complaining
may still do so.  [Ed. - This may be raised to $50.00 in the new year!]

We made one major change to the POSIX.18 draft: The C language feature
is now required. It had been optional.  Our reasoning for this was
twofold.  First, we realized that because there was no requirement
that a given implementation provide a specific language feature,
people could write POSIX.18 compliant applications that would not run
on POSIX.18 compliant implementations!  By requiring C at a minimum,
vendors can guarantee portability of other languages, in particular
FORTRAN and ADA, to all POSIX.18 compliant implementations by writing
their runtime libraries in C.

Secondly, given that POSIX.18 is supposed to codify ``classic UNIX,''
and since classic UNIX has always included a C compiler; albeit the
``classic'' K&R compiler, not c89; we felt it appropriate to require C
language support in POSIX.18.

The working group also made a number of minor editorial changes to the
document, mostly removing redundant text, which brought it down to
less than half its original size!

As for POSIX.14's real purpose, the POSIX multiprocessor profile, we
decided not to ballot the current draft after all.  We had originally
decided to put POSIX.14 out to ballot in March in an attempt to be in
ballot by the time the Profile Steering Committee (PSC) finalized its
rules for ``Standard Posix Profiles.'' We reasoned that if profile
groups that were in ballot at the time the rules were adopted were
grandfathered in such a way as to allow them to ignore said rules,
POSIX.14 might be the only profile to which the rules applied. This
seemed a bit unfair.

It now appears, however, that all profiles will have to follow the PSC
rules before they can come out of ballot.

So we're back to proposing new MP interfaces for POSIX.1 and POSIX.2
that would fill various semantic gaps in MP systems that will be noted
in the POSIX.14 draft.  This includes describing parallel behavior for
a number of common utilities (e.g, make, find, grep, xargs,) as well as
describing special MP features of system administration functions such
as ps(1) and times(2).  We also continue to argue about processor
binding: Can we specify enough of this in an architecture- independent
manner to make it worthwhile.

One interesting point made at the October meeting was that many of the
participants in our working group feel that our major contribution
will not be the MP profile, so much as our monitoring of other POSIX
work to make sure that any new interfaces do not cause major headaches
for MP implementations (e.g, the work that we've already done with
respect to pthreads).  With this in mind, we have proposed a new name
for the group: POSIX.14 - the POSIX reentrancy police!

Volume-Number: Volume 30, Number 8