Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.30/text0010.txt

Text File | 1993-03-11 | 8.5 KB | 180 lines

Submitted-by: [e-mail] (Stephen R. Walli)

Bill O. Gallmeister <[e-mail]> reports on the October 19-23, 1992
meeting in Utrecht, NL:

Summary

Well, for all those of you who've been breathlessly following the
progress of the real-time POSIX proposals these last few months, you
may have noticed a dearth of USENIX updates on the subject.  Blame the
snitch.  He's a slug, and forgot to do the last report.  This report
will cover the last two meetings - July (Chicago) and October
(Utrecht).

The real-time working groups are making quiet, steady progress on
POSIX.4 and POSIX.13, which are two of our proposals that are out to
ballot.  In fact, we fully expect to turn POSIX.4 into a real live
standard on or about January, 1993.  (It depends more on when the high
muckety- mucks of IEEE get around to it than on anything else, in my
opinion).

POSIX.13 is our profile document, which calls out what parts of POSIX
you need in order to run POSIX on your Cray or your cruise missile,
depending on what you may have.  The situation with POSIX.13 is really
pretty interesting, so we'll end with that to give you something to
look forward to.

Rounding out our picture, we have POSIX.4a - threads - which seems to
have completely vanished into the hands of the technical editors.
Those of us who actually would like a useful threads standard sometime
in this century are getting a little impatient.  We have rather little
recourse, however, since documents in ballot are not really the
province of the working group anymore.  Threads is a grown- up
standard now and it'll just have to look out for itself.

And, finally, the Yet More Real-Time additions in POSIX.4b are
proceeding apace in the working group.

POSIX.4: Real-Time Basics

Good news here.  POSIX.4 is actually approaching finalization!  After
a couple of changes that had us a little worried (the addition of
mmap(), and the change to semaphores from binary to counting), we
found the balloting group basically agreed whole-heartedly with the
way things were going.  That's not to say they didn't have plenty of
other things to kvetch about, but then that's what balloters are for.

But at this point, we have passed Draft 13 through a recirculation,
and from what I am told, the initial results look quite promising.
Basically, very little of the POSIX.4 document is open to comment at
this point, and the next circulation should be small, fast, and
quickly resolved.  That done, we can take POSIX.4 to the IEEE
standards board at their June meeting.  It is already in the Committee
Document registration phase at the ISO WG15 level, on its way to
international standardization.

POSIX.4 is one of the last standards that was allowed to pass without
a language-independent specification and test methods.  One of our
next jobs is to produce a version of POSIX.4 in LI form, with test
methods.  A group of volunteers has been formed to start on that work,
and should have some progress to report at the January meeting (but not
much, given the holidays between now and then).

POSIX.4a: (The Long-Lost) Threads

What's going on with threads?  Don't ask us.  We're just the working
group.  As far as I've been able to tell, everyone involved in moving
the threads chapters through their ballot has either lost interest,
had children, gotten out of school and started making the big bucks,
moved to France, or been involved up to their eyeballs in justifying
their own continued existence at their various companies.

I'm told that threads needs to be kick-started a little bit.  In
Utrecht, we had a serious contingent of angry natives wanting to know
what was up with threads.  My prediction (and take it for what it's
worth) is that the threads technical reviewers have until the January
meeting to make some visible progress on their standard, or we might
get some new technical reviewers who are less strapped for time.

POSIX.4b: Extra Real-Time Interfaces

This is a proposal that not many people know too much about, so I'll
give a fast introduction to it.  POSIX.4 was started to extend POSIX.1
for real-time.  POSIX.4 settled on a subset of functionality for
real-time - things we thought were absolutely crucial, and most
importantly, things we could actually make some progress on.  The more
contentious items were left behind for a ``future standardization''
effort.  That effort is POSIX.4b.

The facilities of POSIX.4b are more esoteric and less
widely-applicable, although they are absolutely essential for certain
real-time applications.  POSIX.4b has chapters for:

   - direct application access to interrupts,

   - device control (a.k.a. ioctl(), although we had to change the
     name to protect the existing),

   - spawn() (a combined fork-and-exec which can be more easily
     performed than fork/exec on an MMU-less architecture),

   - Sporadic Server scheduling (a scheduling discipline used in
     conjunction with Rate Monotonic Analysis to support, fittingly
     enough, sporadically-interrupting devices and other things that
     take unpredictable amounts of time),

   - and CPU time monitoring (the POSIX.4 version of times(),
     essentially allowing one thread to monitor the execution time of
     another).

There is also work ongoing on extended memory management, something to
allow one to allocate from distinct, special ``pools'' of address
space (memory attached to a particular bus or device, in particular.)
This chapter is up in the air and might go away.

The POSIX.4b proposal is proceeding along rather fast.  It's a little
terrifying to see a proposal that aims to allow an application to
manhandle an interrupt vector, coming at you full speed ahead.
Luckily, we have the (I hesitate to say it) stabilizing influence of
people from POSIX.1 (who are interested in spawn) and sundry large,
entrenched camps of UNIX aficionados in the group on an intermittent
basis.  Hopefully this influence will help produce something that is
appropriate for standardization.  It would certainly help, in my
opinion, if more mainstream UNIX types were to give us a hand at
UNIX-ifying the POSIX.4b proposal before it hits balloting.  Maybe
some of you nice people can drop in on the working group in New
Orleans in January.

POSIX.13: Real-Time Profiles

This is the fun one.

POSIX.13 was the first profile proposal to hit balloting.  We played
by the rules.  We produced our document.  We formed our balloting
group.  We went to ballot.  We got substantial approval, enough that
very little of POSIX.13 should be open to comment on the next
recirculation.

Oh, did I mention how POSIX.13 breaks just about every rule of how a
profile document should be built?  This unfortunate fact has led to
some hand-wringing among the POSIX powers- that-be.  The Powers would
probably like for POSIX.13 to withdraw itself from ballot (despite the
fact that it's mostly approved by the balloting group) and just go away
until it can be reformed as a good POSIX citizen.

What are POSIX.13's crimes?  Well, it's four profiles, not one.
That's a problem, but not a big one.  We could split the document with
only minimal impact on the Spotted Owl population (and the lumberjacks
would love us).

A bigger problem is that POSIX.13 calls for subsets of POSIX.1.  Like,
a POSIX without the ability to fork() (can't do it on an embedded,
MMUless target), or exit (what sense does that make if you can't
fork()?).

The smaller profiles of POSIX.13 are undoubtedly useful to people
building embedded aplications, however, there's a lot of consternation
that something without a small modicum of UNIX-ness could possibly be
allowed to call itself POSIX.  So, lately, compromise wording was
adopted in the committee whose job it is to make rules about
profiles.  That wording would allow the minimal profiles to be called
``Authorized POSIX Subset Standardized Profiles,'' whereas something
with a real POSIX.1 would be called a ``POSIX System.'' And, of
course, we would still need to convince POSIX.1 to subset itself.

Meanwhile, the POSIX.13 proposed standards are in the hands of - gasp!
- people who are interested in doing real work.  And it is clear that
POSIX.13 would be useful for those doing real work, even if it is
confusing and nasty by POSIX standards.  [ed.-Nasty pun, Bill.]

I predict we'll see an essentially-approved version of POSIX.13 in a
year, which will then have to wait for POSIX.4a to be finalized before
the profiles really mean anything (you can't call out threads support
when there is no threads standard.) I further predict that the POSIX
powers that be will declare POSIX.13 out-of-bounds, and that people
will continue to use POSIX.13 anyway.

Volume-Number: Volume 30, Number 11