Path: gmdzi!unido!mcsun!uunet!ogicse!dali!samsung!cs.utexas.edu!longway!std-unix
From: j...@usenix.org
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.1: System services interface
Message-ID: <619@longway.TIC.COM>
Date: 4 Apr 90 06:52:48 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Lines: 165
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
Posted: Wed Apr 4 07:52:48 1990
From: < j...@usenix.org>
An Update on UNIX* and C Standards Activities
January 1990
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.1: System services interface Update
Mark Doran < m...@inset.co.uk> reports on the January 8-12, 1990 meeting
in New Orleans, LA:
Most published standards inevitably require updating through
corrective supplements. P1003.1 has now reached that stage. The
first supplement, P1003.1a, is at an advanced stage and was the
central issue at the New Orleans meeting.
Also on the agenda were
- further talks with the group working on transparent file access;
- more language-independent-specification work; and
- a run-through of the material in the embryonic second corrective
supplement, P1003.1b.
P1003.1a Ballot Resolution
The first corrective supplement to IEEE 1003.1-1988 (POSIX.1) is
intended to correct errors and oversights in the first publication
with a view to clarifying the intent. It is definitely not meant to
introduce new functionality or behavior into the standard.
This work received its second recirculation ballot during the week
preceding the New Orleans meeting. Donn Terry, chair of P1003.1,
hopes that one, or at most two, more recirculations will bring the
document to a publishable state. Accomplishing this will send it off
to ISO, who will ballot it for six months. (That's right, six months;
an IEEE recirculation ballot lasts ten days -- does this seem a little
lop-sided to you?)
The details of the content of P1003.1a and its ballot resolution are
long and complex, so I won't repeat them here. However, there is one
issue worth raising which the ballot brought to light. On the subject
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
January 1990 Standards Update IEEE 1003.1: System services interface
- 2 -
of changes relating to the support of split baud rates, one balloter
commented:
While we do not agree with the direction this issue is obviously
taking, we will abide with the decision of POSIX insofar as split
baud rates are concerned.
But we would be remiss in our responsibilities if we did not
express our complete outrage with the provincial attitudes
expressed by a number of the ballot comments we have had the
pleasure to review during this recirculation period.
Split baud rates ARE NOT uncommon with a great number of the
community of users of these standards. Obviously, many of those
submitting ballots have not had the opportunity to consider the
needs or requirements of users outside their own immediate view.
We abhor such a limited, irresponsible scope, especially
considering the nature of the tasks we are charged with
resolving. It is our hope that we shall do better in the future.
Only rarely are standards meetings graced with such florid language,
and the balloter clearly has at least the tip of his tongue in his
cheek; however there is, underneath this bonhomie, a serious point
being made...
The IEEE is an ANSI-accredited standards-developing body, responsible
enough to make standards pronouncements for use in the USA. All POSIX
standards are being passed to ISO for potential adoption as
international standards. The POSIX steering committee (SEC) has
declared that POSIX would like to think of itself as an
internationally accessible organization. If POSIX is indeed to be
internationally accessible then the attitudes of some of those who
attend will have to change. Take for instance, the split-baud-rate
issue mentioned above.
Working group discussions revealed that split-baud-rate support,
though a non-issue in the USA, is important in Europe. (The reasons
for this stem from the way the PTTs in Europe structure their charges
for communications lines -- PTTs are Europe's little AT&T
equivalents.) To cut a long story short (and I do mean long; this
particular debate has been going on for over a year...), the P1003.1
working group decided that split baud rates are not important enough
to require explicit support for them in the standard.
And of course this may be quite reasonable. What is unacceptable is
the apparent scorn with which these proposals were regarded by a
minority of the participants in the discussions. If POSIX proceedings
are to lead toward internationally useful standards then all
participants should be mindful of the fact that there is a flourishing
community of users who do not live in the USA.
January 1990 Standards Update IEEE 1003.1: System services interface
- 3 -
Split baud rates are, when all is said and done, not of earth-
shattering importance, nor even terribly interesting; were this an
isolated incident, it would not even be worth mentioning.
Unfortunately, I have encountered this type of attitude on many
occasions. Let's hope that ballot comments like that presented above
reduce this frequency. (``What are split baud rates?'' the American
reader is asking. Serial lines like those plugged into the back of
``dumb'' terminals can be set to transmit at high-speed while
receiving at a lower speed, e.g., 9600 and 75 baud; this can be useful
if you regularly send screenfuls of data to a terminal but only expect
the odd character or two back in the other direction. POSIX supports
this by supplying cf{set,get}{i,o}speed() and tc{get,set}attr() --
that's six interfaces, see? :-)
Transparent File Access (TFA)
The TFA group (now P1003.8) presented several detailed questions about
and the behavior that P1003.1 would like to see from a TFA
implementation in several ``corner cases.'' Dot one's response is that
a few compromises can be made where there are serious performance
issues, but the spirit of the original POSIX.1 should be retained
wherever possible.
On a more interesting note, at a TFA BOFF (Birds OF a Feather
session -- that's a cozy chat after hours), it was suggested that a
subset TFA specification might be produced before the full TFA
specification. Such a specification would not provide full POSIX.1
behavior but would probably be enough to allow POSIX implementations
to connect with existing FTAM and NFS file server machines, which
should suffice for many applications.
Language-Independent Specifications
Last report, I said I hadn't heard a worthwhile justification for this
work or the approach being taken. I still haven't.
P1003.1b
This supplement, still being formed, will be the first to introduce
new functionality into POSIX.1. Highlights so far include symbolic
links, and file-tree walking (more ways to find files and directories
in file systems). If you have a favorite interface which has not yet
made it into a POSIX standard, you might be able to get it in by
proposing it for inclusion in P1003.1b. The cut-off date is likely to
be the April POSIX meeting, so hurry.
January 1990 Standards Update IEEE 1003.1: System services interface
Volume-Number: Volume 19, Number 49
|