Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!
longway!std-unix
From: j...@usenix.org (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.0: POSIX Guide
Message-ID: <408@longway.TIC.COM>
Date: 20 Oct 89 21:49:37 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Lines: 57
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
From: Jeffrey S. Haemer < j...@usenix.org>
An Update on UNIX* and C Standards Activities
September 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.0: POSIX Guide Update
Kevin Lewis < kle...@gucci.enet.dec.com> reports on the July 10-14,
1989 meeting in San Jose, California:
As 1003.0 passes the mid-point of calendar year 1989, progress can be
earmarked by the arrival of line numbers to the guide document. I
remember the first time I saw line numbers on a document within the
IEEE 1003 arena. My first thought was "this committee is really doing
precise, exacting work". Thus was my reaction again when I saw line
numbers on our document. My balloon was burst, when one of our active
members -- and by "active member" I mean someone who commits
contributions in writing, not just someone who comes to voice an
opinion in a talk-show-like atmosphere -- pointed to our ISSUE LOG,
which states that the committee needs to do more work. (There's that
word again.) Alas, I came back down to earth. I have "miles to go
before I sleep."
Dot Zero continues to converge. Our document is finally beginning to
tie together the standards and elements that comprise a POSIX open
system. Key events continue to be the definition of terms that will
eventually make it to the IEEE Glossary and the identification of
areas where terms still need definition.
The group is still generating discussion/debate/argument/food-fights
over behemoth macro-questions such as, "What is the role of the
guide?" and, "What is the PROPER audience?" In addition, the group has
made valiant attempts at addressing specific areas such as graphics
and data interchange without the benefit of focused expertise. We now
agree on our ignorance in these areas, and will seek help and/or to
point to other committees that, we believe, can come up with the
answers.
Overall, we must meet our objective of going to ballot in October
1990, because that is what I told my wife, who is still trying to
figure out what in the world a "dot zero" might be.
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
September 1989 Standards Update IEEE 1003.0: POSIX Guide
Volume-Number: Volume 17, Number 38
Path: gmdzi!unido!mcsun!uunet!samsung!brutus.cs.uiuc.edu!apple!longway!std-unix
From: j...@usenix.org (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.3: Test Methods
Message-ID: <424@longway.TIC.COM>
Date: 20 Oct 89 22:02:11 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Lines: 158
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
Posted: Fri Oct 20 23:02:11 1989
From: Jeffrey S. Haemer < j...@usenix.org>
[ This is a reposting because the original doesn't even appear on uunet. -mod ]
An Update on UNIX* and C Standards Activities
September 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.3: Test Methods Update
Doris Lebovits reports on the July 10-14,
1989 meeting in San Jose, California:
1. Overview
This was the thirteenth meeting of P1003. Monday through
Wednesday, the group began work on a verification standard
corresponding to 1003.2 (Shell and Tools). Following the close
of the formal meeting, the technical reviewers of the draft 10
ballot met for the remainder of the week.
2. Meeting Summary
This was the first meeting to develop the verification standard
for P1003.2, which will contain test methods and test assertions
for measuring 1003.2 conformance. This standard will ultimately
form part III of P1003.3. (Part I contains definitions, generic
test methods, and so forth; part II is test methods for
measuring P1003.1 conformance, including test assertions. As
other P1003 standards reach maturity, their verification will,
in turn, be covered in new parts of the P1003.3 standard.)
The chair's aggressive goal is to be ready to bring part III to
ballot after four quarterly meetings. A detailed schedule and
milestones will be developed at the next meeting.
Attendees included representatives of AT&T, NIST, OSF,
Mindcraft, IBM, DEC, HP, Data General, Cray Research, Unisys,
Perennial and Unisoft Ltd. The meeting agenda included:
o+ the confirmation of new officers for the the part III work
o+ Chair: Roger Martin
o+ Vice-chair: Ray Wilkes
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
September 1989 Standards Update IEEE 1003.3: Test Methods
- 2 -
o+ Technical Editor: Andrew Twigger
o+ Secretary: Lowell Johnson
o+ the rough scheduling and setting of general milestones for
part III
o+ a meeting with the P1003.2 working group to discuss testing
issues
o+ action item assignments
o+ identification of items for the next meeting
In addition, small groups formed to discuss and resolve three
specific issues. One group investigated the difficulty of
thorough testing of the more complex utilities: awk, bc, ed,
lex, make, pax, sh, and yacc. (The resulting action item was to
produce a prototype set of assertions.) A second group scoped
the writing of assertions for BNF type structures: "[]"
expressions, regular expressions, and extended regular
expressions. The third reviewed "Verification of Commands
Interface", a paper by Andrew Twigger of Unisoft Ltd. The paper
covers:
o+ character set and locale
o+ internationalized utilities
o+ underlying OS primitives
o+ regular expression testing
o+ pattern matching notation
o+ utility syntax rules
o+ errors from P1003.1 associated functions
o+ environment variables
o+ standard output format
o+ standard error format
o+ environmental changes
o+ symbolic limits
September 1989 Standards Update IEEE 1003.3: Test Methods
- 3 -
o+ obsolescent features
o+ job control
o+ read-only variables
o+ signal numbers
NIST has contributed its current 1003.2 test assertions to
provide a basis for the 1003.2 verification work. Sheila
Frankel of NIST gave a short presentation on the current state
of the these assertions, which include approximately 900
Mindcraft test assertions, plus 2600 newly-created assertions,
all based on P1003.2 Draft 8.
3. Technical Reviewer's Meeting
In parallel to the verification work for P1003.2, balloting and
revision is taking place on draft 10 of parts I and II.
As of July 6, 1989, 77 responses had been received from the 125
members in the balloting group. Eighteen additional responses
will bring this to the 75% response needed to officially close
the ballot.
The tally of the 77 responses:
28 positive (36%)
31 negative (40%)
18 abstain (24%)
The technical reviewers held a plenary session to evaluate and
respond to the comments and objections to this draft. Group
consensus decided each issue and each decision was final. Part
I was reviewed completely but only a few chapters of part II
were reviewed. The remaining part II work was assigned to
volunteers.
Draft 11 is planned for ballot recirculations in October, 1989,
and an approved standard for parts I and II is anticipated by
the first quarter of 1990.
September 1989 Standards Update IEEE 1003.3: Test Methods
Volume-Number: Volume 17, Number 39
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!bionet!apple!longway!std-unix
From: j...@usenix.org (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <410@longway.TIC.COM>
Date: 20 Oct 89 22:05:45 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Lines: 108
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
From: Jeffrey S. Haemer < j...@usenix.org>
An Update on UNIX* and C Standards Activities
September 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.4: Real-time Extensions Update
John Gertwagen reports on the July 10-14, 1989 meeting
in San Jose, California:
The P1003.4 meeting in San Jose was very busy. The meeting focused on
resolving mock-ballot objections and comments. Despite limited
resources for documenting changes, a lot of work got done. Here's
what stood out.
Shared memory
The preferred interface falls somewhere between shared-memory-
only and a mapped-files interface, such as AIX's mmap(), which
allows files to be treated like in-core arrays. Group direction
was to reduce the functionality to support only shared memory, so
long as the resulting interfaces could be implemented as a
library over mmap().
Process memory locking
The various region locks were clarified and, thus, simplified;
the old definitions were fuzzy and non-portable. For those who
haven't seen it, there is actually a memory residency interface
(i.e., fetch and store operations to meet some metric) instead of
a locking interface. Most vendors will probably implement it as
a lock, but some may want it to impose highest memory priority in
the paging system.
Inter-process communication
Members questioned whether the interface definitions could really
support a broader range of requirements; they're like no others
in the world today. Having been designed to meet the real-time
group's wish list, there are lots of bells and whistles -- far
more than in System V IPC -- but it's not clear, for example,
that they are network extensible. Discussions in these areas
continue.
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
September 1989 Standards Update IEEE 1003.4: Real-time Extensions
- 2 -
Events and semaphores
Members were concerned about possible overlap with other
mechanisms, especially those being considered for threads. The
question is basically, "Should there be separate functions for
different flavors or a single function with multiple options?"
General sentiment (including our snitch's) seems to be for
multiple functions; however an implementation might choose to
make them library interfaces to a common, more general system
call. There is, however, a significant minority opinion the
other way.
Scheduling
Many balloters found process lists and related semantics
confusing. An attempt was made to re-cast the wording to be more
strictly in terms of process behavior.
Timers
Inheritance was brought in line with existing (BSD) practice.
Outside of the mock ballot, there were two other major news items.
First, there is a movement afoot to make the .4 interfaces part of
1003.1. They would become additional chapters and might be voted
separately or in logical groups. This would bring P1003 in line with
the ISO model of a base standard plus application profiles. POSIX.4
would become the real-time profile group. This is a non-trivial
change.
Up to now, the criterion for .4 has been that of "minimum necessary
for real-time", and has coincidentally been extended to support other
requirements "where convenient". This is not a good starting point
for a base interface. For example, mmap(), or something very much
like it, is probably the right base for "shared storage objects", but
real-time users want an interface for shared memory, not for mapped
files. Our snitch worries that things might look a bit different had
the group been working on a base standard from the beginning.
Second, the committee officially began work on a threads interface,
forming a threads small group and creating a stub chapter in the .4
draft. A working proposal for the interface, representing the
consensus direction of the working group, will be an appendix to the
next draft.
A lot of work remains to be done before .4 can go to ballot and the
current January '90 target may not be realistic. If the proposed re-
organization occurs, a ballot before the summer of 1990 seems unlikely.
September 1989 Standards Update IEEE 1003.4: Real-time Extensions
Volume-Number: Volume 17, Number 40
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!
longway!std-unix
From: j...@usenix.org (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.5: Ada-language Binding
Message-ID: <411@longway.TIC.COM>
Date: 20 Oct 89 23:08:44 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Lines: 140
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
From: Jeffrey S. Haemer < j...@usenix.org>
An Update on UNIX* and C Standards Activities
September 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.5: Ada-language Binding Update
Ted Baker reports on the July 10-14, 1989
meeting in San Jose, California:
The Ada-language binding for 1003.1 is progressing steadily, though
behind schedule. The group agreed to try to prepare a document for
the October meeting in Brussels that is ready for mock ballot. Those
at the meeting will decide whether the document has achieved this
goal. If not, we will try again at the January meeting in New Orleans.
The slow progress is mainly due to the long time between meetings and
the limited workforce available to do the writing. The members, all
volunteers, must steal time for POSIX from their "real" (i.e. paying)
jobs. Attending quarterly meetings already puts most members near the
limit of time they can spare.
Most significant technical issues seem to be resolved; the remaining
controversies center on almost-religious issues, such as the exact
grouping of interface declarations into Ada packages, naming,
capitalization conventions, and where to strike the balance between
providing full functionality and idiot-proofing the interface.
Each chapter has been assigned to a person for review and editing,
based on decisions made at the San Jose meeting. Quite a lot of
writing still needs to be done. Chapter 7 ("Device- and Class-
Specific Functions" --i.e. terminal interfaces) is still empty, and
some others are still mostly just Ada code, with no discussion. Most
of the rationale remains to be written. Mitch Gart has agreed to
coordinate this, including a chapter on "meta-issues" -- design
decisions affecting the entire interface. David Emery will combine
the chapters to produce the next draft.
Interaction with 1003.4 (Real-Time Extensions) has heated up, with
1003.4's consideration of support for multi-threaded processes. Ada
language implementations must support multiple tasks (i.e. threads)
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
September 1989 Standards Update IEEE 1003.5: Ada-language Binding
- 2 -
within a POSIX process, to comply with the Ada language standard.
Neither the 1003.1 standard nor the 1003.4 draft that just completed
mock balloting supports multithreaded processes, so the Ada
implementor is currently forced to hack out some sort of internal
concurrency scheme, with its own layer of dispatching, for each Ada
process. This tends to run aground when one Ada task makes a blocking
system call, since the whole process is forced to wait. Naturally,
Ada implementors and users would be pleased if the POSIX interface
provided for concurrency within a process.
The Ada group is very interested in the threads proposal, and most
members would like to see some support for threads in the 1003.4
standard that goes to formal ballot. Some members are a little bit
concerned that those working on the proposal may not understand Ada
tasking well enough to insure that the proposed threads will be
adequate to implement Ada tasking semantics. This has been very
frustrating for members of the Ada group, since the discussions of the
threads proposal were all in parallel with meetings of 1003.5. The
best the Ada group was able to do was to keep one observer present (on
rotation) at the review of the threads proposal. It is not clear
whether this was adequate.
[Editor's note: What's going on here, and in the second paragraph, is
that some groups are much larger than others. 1003.5 is among the
smallest. The 1003.4 session I saw had about forty, overworked
attendees. The 1003.5 sessions I saw had five to ten.
1003.5 could use a lot more participation from the Ada community.
Unfortunately, this may be a case of "once burned, twice shy". For
years, there's been a lot of talk about "Ada environments", all of
which seem, from a UNIX perspective, like enormous, cumbersome
projects that might actually come into widespread use in, if not our
children's lifetimes, perhaps their children's.
Make no mistake about it: the Ada community is huge. And easy
availability of machines with implemented, Ada-language bindings to
POSIX-conformant operating systems would be immensely useful to that
community. The ability to buy a box, off-the-shelf, with a portable
environment for running Ada programs in the next couple of years,
would make Ada programmers' lives immensely easier and even be a big
aid in implementing the richer and more complex environments mentioned
in the previous paragraph.
Still, you can guess what the average, UNIX-naive, Ada programmer must
think: "Whoopie, another standard/environment. I'll have to take a
look at it in a few years to see how it's coming along." If the IEEE
could make some non-vanishing fraction of the Ada community understand
that POSIX is on the verge of being here, now, dot 5 might get a lot
more help.
This seems to us (that's the editorial "we", folks) like a
September 1989 Standards Update IEEE 1003.5: Ada-language Binding
- 3 -
quintessential marketing problem. If 1003.5 could enlist the help of
1003.0 in this matter, they might be able to make some real headway
here. ]
The 1003.5 group is also very interested in the progress of the
language-independent versions of the POSIX standard. Much of the
labor of the Ada binding group has been devoted to separating the
essential semantics of the 1003.1 interface from the details of its
expression in the C language (for example, setjmp()/longjmp(), and
signal handlers). This labor may be of use to those working on the
language-independent version of 1003.1, but the Ada group does wish
that new standards, such as 1003.4, would start out with a language-
independent document, rather than adding to the language-bias problem.
There was one change in the leadership of the 1003.5 working group.
Stowe Boyd, of Meridian, had been vice-chair but is no longer able to
spare time from his job to work on this project. Steve Deller, of
Verdix, has agreed to replace him. This is a very important job,
since the vice-chair of the 1003.5 group takes direct responsibility
for setting the technical agenda and running meetings.
September 1989 Standards Update IEEE 1003.5: Ada-language Binding
Volume-Number: Volume 17, Number 41
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!
longway!std-unix
From: j...@usenix.org (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.7: System Administration
Message-ID: <413@longway.TIC.COM>
Date: 21 Oct 89 03:09:21 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Lines: 107
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
From: Jeffrey S. Haemer < j...@usenix.org>
An Update on UNIX* and C Standards Activities
September 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.7: System Administration Update
Steven J. McDowall < s...@mca.mn.org> reports on the July 10-14, 1989
meeting, in San Jose, California:
War and Remembrance - How I survived a Posix Meeting
Listen closely to this tale of wonder and bewilderment and hope that
you shall never have to face such horrors as I. Yes, I was there
when, in a flurry of activity, the 1003.7 committee elected Steven
Carter to the chair. To show he was a good choice, Carter immediately
sat on the chair to which he'd been elected. This was swiftly
followed by the election of Vice-chairs Martin Kirk and Dave Hinnant
(though I shall speculate not on what vices they may have perpetrated
on those chairs); Mark Colburn, Secretary (owing to a proven ability
to take dictation lying on a pool-side sun bed); and their honors Bob
Bauman and Shoshana O'Brien, Technical Editors.
You may sense that I feel few exciting things happened in San Jose.
Correct. I wish this group would get into some real fights, like
other groups. Interoperability may prove our only hope. Still,
progress is progress, however uncontentious. Here's what else seemed
to me to be important.
1. Language Independence
The group voted, nearly unanimously, that the country of
Language should be independent. We were uncertain about where,
precisely, it might be, but tentatively put it near Borneo.
We chose to use ASN.1 ("Abstract Syntax Notation - 1") as our
internal notation for data structures. The group also appointed
me representative to the 1003.1 language-bindings group to watch
what those pursuers of knowledge are doing in this area.
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
September 1989 Standards Update IEEE 1003.7: System Administration
- 2 -
2. Interoperability
X/Open continues to push this into the foreground. Luckily for
us, they also continue to help us understand what it entails.
Group consensus holds that interoperability is within the
purview of 1003.7. What we're still uncertain of is how far
down we should standardize; only through the application layer?
down to the packet layer?
For example, a standard application-layer protocol insuring
interoperability might require that certain Application Program
Interface (API) calls be available, with given arguments and
results, but say nothing about how those calls are made. In
contrast, a transport-level protocol might require that the
information be fed into the API will be in a pseudo-ASN.1 format
to help in non-homogeneous networks. A still lower level
protocol might detail the exact packet structure, including
ASN.1 format for the object data, to prevent foreign machines in
a non-homogeneous network from throwing out otherwise
unrecognizable packets.
Most committee members have strong, idiosyncratic ideas about
this subject and the issue is certain to re-surface in Brussels.
We need input on this from the community at large. Where do YOU
think a standards organization like the IEEE should draw the
line in ensuring interoperability?
[Editor's note -- This is not a rhetorical question. Things you
do in the future may be affected by decisions P1003.7 makes in
this arena. If you have an opinion on this subject, speak up.]
As an aside, the current X/OPEN representative, Jim Oldroyd of
the Instruction Set, Ltd., who has really helped the group a
great deal in this area, may not attend the next 1003.7 meeting.
We think this would be a real loss, and hope that X/OPEN and his
employer find a way to arrange for him to go.
3. Misc.
Some progress was made in doing the ASN.1 syntax for a few of
the basic objects the committee decided on for phase I of the
standard. Everyone is discovering that defining such objects
(File Systems, Devices, Spools, etc.) in a non-ambiguous way
using a meta-language like ASN.1 might not be as easy as we
first thought. Live and learn, eh?
September 1989 Standards Update IEEE 1003.7: System Administration
Volume-Number: Volume 17, Number 43
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!ginosko!usc!
apple!longway!std-unix
From: j...@usenix.org (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.11: Application Transaction Processing
Message-ID: <416@longway.TIC.COM>
Date: 23 Oct 89 20:14:31 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Lines: 78
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
From: Jeffrey S. Haemer < j...@usenix.org>
An Update on UNIX* and C Standards Activities
September 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.11: Application Transaction Processing Update
Bob Snead reports on the July 10-14, 1989 meeting
in San Jose, California:
1003.11 (application transaction processing, or TP) is one of two
recently approved working groups -- the other being P1003.10
(supercomputing) -- whose charter is to write an application
environment profile (AEP). A profile is simply a list of pointers to
existing standards within the POSIX OSE (Open System Environment).
Where the group finds functionality missing from this set of
standards, the group may either commission its definition by some
other POSIX group or write a new PAR to request that IEEE create a
standard in the area.
This was our first meeting as 1003.11; the previous three meetings
were as a study group. This study group was formed last year at the
Ft. Lauderdale meeting to investigate the feasibility of extending
POSIX into transaction processing. In those first three meetings
there was consensus that POSIX should address transaction processing.
At this point, the TP group is reviewing existing standards in detail
to find out what's already been done. To this end, they have split
into two subgroups, one to review models, the other to search out and
review other relevant standards. There seems to be some consensus
that once we understand what is available, there will still be new
interfaces to define.
TP under Unix is currently sort of a funny domain. Database vendors
believe that transaction processing is theirs. They build TP
primitives into their products that let application developers define
transactions over modifications to data. More and more UNIX
application developers want, instead, to write applications that bind
a group of modifications to data managed by assorted vendors products,
including multiple databases, screen managers and file systems.
Sensing this need, X/OPEN boldly chartered a group to define such
services. In addition, ISO, some time ago, recognized the need for
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
September 1989 StandarIdEsEEUp1d0a0t3e.11: Application Transaction Processing
- 2 -
services to define transactions which span heterogeneous open systems,
and began a group to define such services. ISO also has groups
defining CCR (Commitment, Concurrency, and Recovery) and RDA (Remote
Data Access), each of which is an essential part of TP, especially
distributed TP.
Both efforts are pretty far along. X/OPEN has defined a model and a
set of interfaces but, since they are not a real standards body,
referencing their work may present some problems for P1003.11. The
ISO group recently resolved all outstanding objections to their model,
services and protocols. What remains for us then is to place the
relevant portions of their work into a POSIX framework, filling in the
holes.
September 1989 StandarIdEsEEUp1d0a0t3e.11: Application Transaction Processing
Volume-Number: Volume 17, Number 46
Path: utzoo!attcan!uunet!longway!std-unix
From: j...@usenix.org (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.8/1: POSIX Transparent File Access
Message-ID: <452@longway.TIC.COM>
Date: 2 Dec 89 17:52:17 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Lines: 216
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
From: Jeffrey S. Haemer
An Update on UNIX* and C Standards Activities
December 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.8/1: POSIX Transparent File Access Update
An anonymous correspondent reports on the July 10-14, 1989 meeting, in
San Jose, California:
[Editor's note -- Though this report came in substantially later than
the other July reports, I think it's still useful, provocative, and
well worth reading. -jsh]
Overview of New 1003.8 Developments
1. All standards produced by POSIX committees (with the exception
of language-binding standards like 1003.5 and 1003.9) must be
specified in a language-independent fashion, and must include at
least one language-specific binding. Since P1003 will not have
guidelines and rules for constructing a language-independent
specification before April 1990, no POSIX networking group can
possibly ballot a document before July 1990. "Mock" ballots
(aka trial-use ballots) are unaffected by this, but their
usefulness will be diminished.
2. Two new POSIX Networking working groups either have submitted or
will soon submit PARs to begin work, bringing the total number
of POSIX Networking working groups to six. These new groups are
the Name Space and Directory Services Interface and the X.400
Mail Gateway Interface. [Editor's note -- The SEC approved the
PAR for the former, but decided that the latter transcends
POSIX, and recommended that the IEEE form a separate, numbered
group, analogous to 1003 or 1201, to handle X.400. See below.
-jsh]
3. Due to the rules governing IEEE and IEEE-TCOS standards
activities, as well as the logistical nightmare six sub-working
groups cause, the hierarchical structure of the P1003.8 POSIX
networking committee will be flattened out, with each current
sub-group submitting PARs to cover their current work.
Coordination will be provided by a "POSIX Networking Steering
Committee", made up of the chairs and vice-chairs of each
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access
- 2 -
networking-related working group and the current chair and
vice-chair of 1003.8. [Editor's note -- This is still being
debated by the SEC. -jsh]
4. Since each of the 1003.8 sub-groups will be submitting separate
PARs, the P1003 Sponsor's Executive Committee (SEC) is taking
the opportunity to evaluate the degree to which each PAR is
intended to represent a part of the "POSIX Environment" or is a
component which has no relationship to the rest of POSIX and
should, hence, stand alone. The result of this is that several
of the 1003.8 sub-groups may be issued project numbers outside
of the P1003 family. There is some precedent for this; the X11
interface group was assigned project number P1201 for just this
reason.
Activity in the TFA Subgroup, P1003.8/1
The group is making slow but steady progress towards the goals of a
fully-specified programmatic interface for networked file access and
the semantics and suggested syntax for administrative interfaces for
such a functionality. The group is dominated by a faction, apparently
lead by Sun Microsystems, with a goal of ensuring that NFS, in some
form, is a sufficient mechanism to provide the service required by the
"full TFA" interface. The balance of the committee is composed of
people who simply want a standard they can use as an acquisition tool.
Achievements
+ Enough consensus and material was obtained to permit development
of a first draft of the programmatic interface part of the
specification; this draft should be complete in time for the
second mailing, due out on September 8.
+ Liaison activities with 1003.7 (System Administration) continued;
.7 indicated that all of the options for the TFA mount/unmount
model were, in fact, of use in administering such a system. They
also agreed that they owned responsibility for all file-system
commands not completely unique in function to TFA, and that they
would pursue input from the TFA group when the time was right.
+ Further progress was made on identifying status and usage
information which must be obtainable from the provider of a TFA
service.
December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access
- 3 -
Problem Areas
1. Representation in the group is unbalanced; there is, as of this
time [Editor's note -- July, '89 -jsh], no substantial
representation of the "stateful" side of the semantic issues.
The chairman has, so far, been unsuccessful in encouraging a
more balanced group viewpoint so representation from the
stateful camp has been solicited (with minimal success) for
future meetings.
2. Several "grey areas" in the semantics of IEEE 1003.1-1988 have
been identified by the TFA group over the last several months.
The suggested "fixes" have been slanted in a way that would let
the TFA interface avoid relaxing 1003.1 semantics while
permitting a stateless implementation of the TFA service; i.e.
rather than strengthening 1003.1 to define the actual behavior
of a single stand-alone system, the proposals have been so weak
that they underconstrain single-system behavior. It appears
that the majority of the 1003.1 committee will not approve of
this approach, and will require the "fix" to be of the proper
strength to correctly specify single-system behavior.
Let me give an example. The original 1003.1 standard is silent
on the issue of when the effects of a write are visible to a
subsequent read of the same byte of the file. If process A
writes byte 123 of file "foo", then process B does a read of
byte 123 of file "foo", at what point is B guaranteed to see the
byte A wrote?
Immediately? If so, stateless solutions employing read caches
fail; if process B is remote on system "bsys" and reading the
file via NFS, byte 123 might come out of the file cache on bsys
and not from the file cache on the system where A lives.
Immediately if A and B are on the same system, and at some
implementation-defined time otherwise? This requires 1003.1 to
define what it means by "the same system", and doesn't
adequately address multi-processor single systems with
"interesting" caches. It also means a truly portable
application that is interested in running in a distributed
environment can *never* know when the byte written by A is
visible to B.
Only in the presence of byte locking? In other words, A locks
byte 123, writes it, unlocks it; if B then locks and reads 123,
it is guaranteed to see what A wrote. Not a bad solution, but
it breaks existing applications and in fact is a relaxation of
the intended semantics of 1003.1.
Basically, the "intent" developing in 1003.1 is that the effect
of the write must be seen immediately by any other process with
December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access
- 4 -
that file open, without regard to process location, without
recourse to O_SYNC mode opens, without the necessity for
locking, and so on. 1003.1-1988 is silent on the issue; the
proposed fix from TFA (basically a compromise I did not like and
knew would fail) was that read-after-write be guaranteed only
for co-located processes and in the presence of locking. This
gave 1003.1 a chance to avoid relaxing their intended semantics
while leaving TFA a "loophole" to change semantics without
having to indicate a change in wording from 1003.1.
This is what got rejected by 1003.1, which is getting pretty
damned tired of TFA's trying to claim that the full TFA
semantics are "just like" 1003.1 but with gaping differences
that are introduced silently due to weak or weasel wording in
1003.1-1988.
3. 1003.7, System Administration, is making distressingly slow
progress. If this continues, 1003.8 will have two choices with
respect to client-side administrative commands:
- Do not standardize them; give feedback to 1003.7 and wait
for them to complete their specification. This risks
incompatible implementations.
- Standardize them insofar as they relate to TFA
administration. This risks incompatibility between the TFA
aspects of those commands and their more general aspects.
An example is the "mount" command; if 1003.7 is unhappy
with the form of the TFA mount command, they are under no
constraint to remain compatible with it. If the group
ballots far enough in advance of 1003.7, this sort of clash
could be frequent.
4. Many of the contentious issues have been "resolved" through the
various mechanisms POSIX provides for introducing optional
behavior; most frequently, these involve either
"implementation-defined" behavior, or the addition of path-
specific attributes whose status can be determined through the
pathconf() function. Several of these options should be viewed
by the ballot group as being "gratuitous" in some sense, i.e.
the TFA committee should take a stand one way or another, and be
willing to be beaten up in ballot for it. The POSIX standards
are wishy-washy enough without the addition of gratuitous
options.
December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access
Volume-Number: Volume 17, Number 80
|