From: n...@usenix.org (Nicholas M. Stoughton)
Subject: Standards Update, POSIX.1: System API
Date: 1995/04/12
Message-ID: <3mh8j0$h8d@cygnus.com>
X-Deja-AN: 100371656
approved: s...@cygnus.com (Moderator, Sean Eric Fagan)
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 API
Nick Stoughton < n...@hoskyns.co.uk> reports on the January
16-20, 1995 meeting in Ft Lauderdale, FL:
If You Can't Beat 'Em, Join 'Em
Well, after tiring of twisting people's arms (usually
unsuccessfully) to snitch on the work of the POSIX.1 Working
Group, where I am usually to be found during a POSIX meeting
myself, I thought I would have to submit at least one real
snitch report myself. Show everyone how its really done ...
but the only trouble is, I have all those other great
snitch's on the other groups to live up to!
POSIX.1 is a small group, typically only about 6 or 7 show
up at a meeting. Until this meeting, it had only two items
of work: POSIX.1a and Interpretation requests. However, a
new Project Authorization Request has just been passed and
assigned to this group, so perhaps I'll have some more
people to dragoon in April!
Another Year, Another Draft
The great highlight of the January meeting was that Lee
Damico, our technical editor, had managed to ship draft 12
of POSIX.1a to the IEEE a week before the meeting. This was
after many late nights, weekends, and even sacrificed
Christmas vacation trying to get all the ballot resolutions
into the draft.
Several sections were substantially rewritten after the
first round of ballotting; most notably the checkpoint-
restart interfaces. These are highly contentious for a
number of reasons:
- They are not based on existing practice, and are
substantially invention by the committee. As a Usenix
and Europen (the European equivalent of Usenix)
representative, this makes me decidedly uneasy.
However, they are optional, and I don't believe they are
unimplementable. Lets hope some brave reader tries to
build these interfaces before the standard is published
so we can have some existing practice and experience to
work with!
- Two different groups within POSIX require them for
future extensions. The Batch profile, which was
- 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002 -
responsible for wording the original (up to Draft 11)
version, needs some interfaces to allow long running
jobs to be stopped in their tracks and restarted later.
In addition, the work being done by the Services for
Reliable, Available, Serviceable Systems (SRASS) working
group need interfaces to checkpoint processes if the
system is failing, to allow those processes to be
restarted later in, potentially, a quite different
environment after various devices have disappeared and
so on.
The batch and SRASS arguments look set to roll on for some
time; the two groups want quite different things. However,
it is also undesirable to have two different checkpoint
interfaces, one for batch, one for SRASS. The ballot group
just hate the whole idea because it is invention. But if we
remove the interfaces, then these two follow-on groups are
in trouble.
The other recurrent long-running argument in POSIX.1 is over
the interpretation of trailing slash characters on
pathnames. Historically, System V based systems ignored all
trailing slashes, whatever. BSD based systems only permitted
trailing slashes on pathnames that were existing
directories. In draft 12, the BSD behavior is demanded. From
an engineering perspective, this is a much cleaner answer.
However, the weight of existing System V platforms that
would lose compliance as a result of this is substantial.
>From the application developer's, as opposed to the system
implementor's, point of view, it is a good change. If you
wrote an application that depended on trailing slash
behavior before POSIX.1a, it was not portable. After the
publication (well, we have to be optimistic), such an
application _w_i_l_l be portable.
For most system implementors it is not too hard a change to
get working in a future release, and most have at least one
release a year.
News Flash
As ballot co-ordinator for POSIX.1, I can tell you that the
ballot on draft 12 closed on time, with a 44% affirmative
vote. Most of the ballots look as if we should be able to
work through them quickly, so progress can be expected in
April.
Volume-Number: Volume 35, Number 26
|