Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!
apple!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.0 POSIX Guide
Message-ID: <385@longway.TIC.COM>
Date: 31 Aug 89 20:03:12 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 70
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
An Update on UNIX* and C Standards Activities
August 1989
Jeffrey S. Haemer, Report Editor
USENIX Standards Watchdog Committee
IEEE 1003.0: POSIX guide Update
An anonymous correspondent reports of the April, 1989 meeting:
The April session of 1003.0 was fruitful. The most significant
accomplishment was the proposal and development of definitions the
committee feels it needs to describe an open systems environment
properly and adequately. Five definitions were developed:
o+ open system environment
o+ application environment
o+ application environment description
o+ application environment profile
o+ POSIX open system environment
Group consensus was that the first four would be submitted to the JTC1
Application Portability Study Group as a draft proposal for its work.
The committee added the caveat that these were draft definitions,
subject to change. A key clarification by these definitions was the
distinction between an application profile and an open system
environment: a profile is a subset of the environment.
The guide document, being developed by 1003.0, is nearly mature.
Significant strides were made in the architecture section, which
focuses on the operating system interface, languages, and network
services. In the following months, 1003.0 will turn its attention to
database management, data interchange, and graphics. The user
interface section will be closely coupled to the work of the newly
formed, IEEE 1201.1 (Xwindows) working group. Similarly, the the
transaction processing section will track the on-line transaction
processing (OLTP) group (1003.11).
There is some worry about the length of the guide -- currently 135
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 2 - IEEE 1003.0: POSIX guide
pages and growing. If the document becomes unwieldy, some attention
will be turned to scaling it down.
The committee also created an Internationalization study group, to cut
across groups and help increase inter-group coordination in this area.
The study group intends to become a full working group in Brussels,
this October.
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
Volume-Number: Volume 17, Number 16
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!tut.cis.ohio-state.edu!
brutus.cs.uiuc.edu!apple!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.1 System services interface
Message-ID: <384@longway.TIC.COM>
Date: 31 Aug 89 20:01:09 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 70
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
An Update on UNIX* and C Standards Activities
August 1989
Jeffrey S. Haemer, Report Editor
USENIX Standards Watchdog Committee
IEEE 1003.1: System services interface Update
Shane McCarron < a...@bungia.mn.org> reports of the April, 1989 meeting:
"After thinking about it, I realized that 1003.1 did actually do some
stuff this quarter." [April -ed]
1003.1 is preparing two supplements, A and B, to 1003.1-88.
At the 1003.1 meeting in Minneapolis, the group reviewed draft 0.1 of
1003.1, supplement A. This supplement contains only clarifications
and editorial comments, and will be balloted in the Summer. It will
be provided to the ISO as the United States' comments on the
International Standard IS9945, which is the same as 1003.1-1988. Its
goal is to insure that the ISO standard and the the IEEE standard
(with supplement) are functionally identical.
Supplement B, to be balloted later, contains substantive changes: new
facilities absent in IEEE Std 1003.1-1988. Some were missing from
1003.1-88 because they weren't completely specified in time to be
included in the first release of the standard. Others are being
introduced due to requests from other standards committees or the user
community. For example, the ISO working group responsible for POSIX
has requested a new archive format. It argues both that the archive
formats in the first standard are insufficient for the future needs of
POSIX systems and that a dual solution is unacceptable. The new
format uses ANSI standard labeling, but extends it to permit POSIX
filenames, security information, etc.... Supplement B also includes
symbolic links, truncate(), ftruncate(), putenv(), clearenv(),
getpass(), seekdir(), telldir(), chroot(), fchmod(), fchown(), and
fsync().
Supplement B will also contain additional clarifications and edits to
the base standard. The ISO will probably designate this supplement an
addendum to IS 9945. All this maneuvering insures that the different
standards stay in sync, and prevents large delays in getting the ISO
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update -IE2EE-1003.1: System services interface
standard approved.
Although 1003.1-88 is now official, the 1003.1 committee's work will
continue for some time yet. As other POSIX standards gel, their
committees uncover requirements for additional functionality or
semantics in the base standard, to support their work. As these
committees point out such cavities in the standard, P1003.1 works to
fill them. Everyone's hope is that no root canals will be necessary.
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
Volume-Number: Volume 17, Number 15
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!
apple!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.5 Ada Language
Message-ID: <376@longway.TIC.COM>
Date: 23 Aug 89 19:16:31 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 90
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
An Update on UNIX* and C Standards Activities
August 1989
Jeffrey S. Haemer, Report Editor
USENIX Standards Watchdog Committee
IEEE 1003.5 Ada Language Update
Ted Baker (tba...@ajpo.sei.cmu.edu) reports of the April 1989 meeting:
The Minneapolis meeting started off poorly. The chairman, co-
chairman, and technical editor were absent, though each for good
reasons. ("Co-chairman" is POSIX for vice-chairman.) Only one of the
members present had received a copy of the latest draft (2.0). Many
of the changes agreed upon at the last meeting (Fort Lauderdale) were
not yet reflected in this draft. There was no agenda.
Despite these handicaps, the group made considerable progress. Steve
Deller acted as chair, working up an agenda and holding the group
fairly closely to it. (Indeed, Steve Deller has now become an
official co-chair, but is still doing a good job.)
By the second day copies of Draft 2.0 had been made. This draft was
reviewed completely, and several changes were approved. The hottest
issue was how signals would be mapped to Ada task entries. Several
semantic gaps in the P1003.1 C-language binding were discovered, and
passed on to the P1003.1 working group.
Most major semantic issues were, at this point, resolved.
1. Each Ada program consists of a single POSIX process, or at least
appears to be so through the POSIX/Ada interface.
2. POSIX signals are handled by Ada tasks via the same mechanism as
hardware interrupts, as logical entry calls.
3. POSIX character and string types are distinct from the standard
Ada character and string types.
4. The C-binding's "errno" values are translated into distinct Ada
exceptions.
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 2 - IEEE 1003.5 Ada Language
5. The Ada-binding need not follow the organizational and naming
conventions of the C-binding, especially where they violate
principles of data abstraction.
What remains is filling in a lot of details, including most of the
text of the document, and making it stylistically consistent.
Group members volunteered to edit the agreed-upon changes into the
draft document, while filling in missing text. This work was to be
completed before May 10-12, at which time a subset of the working
group would meet in Bedford Mass. for a "writing party". The goal of
this party would be to catch up, completing all missing portions of
the draft, so that it could be submitted for mock ballot before the
July P1003 meeting. There was some question whether this goal would
be met. (The mock ballot date was missed, so it appears 1003.5 won't
have an official Ada language binding that corresponds to 1003.1 by
end-of-year 1989.)
There were also coordination meetings (BOFs) with the groups working
on language-independent specifications (P1003.1) and threads
(P1003.4). The Ada group seemed generally pleased with progress on
the language-independent specification, and hopes that the draft Ada-
binding will provide some guidance to that activity. The group is
less pleased with the tendency of other groups (e.g. P1003.2 and
P1003.4) to aggravate the problem of C-dependencies in their draft
documents.
The Ada group is very interested in having the 1003.4 standard include
multi-threaded processes, but is very concerned that any such standard
be compatible with the semantics of Ada tasks. Some of the preliminary
proposals coming out of the threads working group do not seem to be
compatible with this goal.
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!
apple!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.8 Networking
Message-ID: <406@longway.TIC.COM>
Date: 20 Oct 89 20:28:40 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 386
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
[ I can't seem to find a copy of this in my archives, which probably
means that I neglected to post it with the others in August.
If not, and you've already seen it, please ignore this one. -mod ]
An Update on UNIX* and C Standards Activities
August 1989
Jeffrey S. Haemer, Report Editor
USENIX Standards Watchdog Committee
IEEE 1003.8 Networking Update
Steve Head (s...@hpda.hp.com) reports on the April 1989 meeting:
OVERVIEW
P1003.8 is the IEEE POSIX networking standards committee, working on
network standard interface definitions for POSIX. The committee is
divided into several subcommittees, including transparent file access,
remote procedure call, network IPC, and MAP. There were about 30
attendees at P1003.8 altogether. This is a report on the network IPC
subcommittee, which is creating both a "sophisticated" interface and a
"naive" interface for interprocess communications. Because it is not
yet known whether the group's work will all go into a single standard,
the word "standard" should probably be "standard(s)".
At the April meeting, the group redefined the goals of the two
interfaces, and adopted a top-down methodology to avoid factional
deadlock. It went on to set initial milestones for the end-product
standards, complete a first pass of functionality and objects of
interest, and initiate discussion and cooperation with other
organizations and committees working in related areas.
DETAIL
At this meeting, the main topics of discussion were:
1. Goals
2. Methodology
3. Milestones
4. Functionality and Objects
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 2 - IEEE 1003.8 Networking
5. Relationships to Other Organizations, Standards, and Evolving
Standards
6. Naming
7. Async Events
8. XTI versus sockets
9. e-mail distribution list
10. Future Agenda
Note: in this report, "XTI" refers to X/Open's Transport Interface, a
networking interface definition for UN*X based primarily on AT&T's TLI
(Transport Library Interface). "CNI" refers to the Chemical Abstracts
Company Network Interface, an independently developed transport level
interface which is designed run not only on UN*X but other operating
systems as well. "Sockets" refers to the popular, 4.3-BSD-based
networking interface.
1. Goals
Several new goals were added over the week to the list of existing
goals that had been developed for the sophisticated interface at the
previous meetings.
o+ timeliness of getting the standard to the industry
o+ usability -- the standard must be fully usable, without dangling
dependencies
o+ quality -- not repeat the "mistakes" of predecessors (XTI,
sockets, and CNI)
o+ compatibility -- preserve user investment in existing interfaces
(XTI, sockets, etc.)
In review, the two interfaces share the following goals:
o+ ability to provide client-server support
o+ virtual-circuit- or datagram-level service
o+ accommodate POSIX to non-POSIX datacomm
o+ support for multiple protocol suites and multiple networks in 1
machine
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 3 - IEEE 1003.8 Networking
o+ few "system calls" per logical operation, though the naive
interface will probably be less efficient than the sophisticated
interface
In addition, the sophisticated interface wants:
o+ protocol-independent access to protocol-specific features
o+ sophisticated (POSIX real-time) event management of protocol
interface
o+ provision for support of [existing] protocol-specific features
o+ "clean" feature availability
o+ integration with POSIX I/O routines (read()/write())
o+ easy extensibility to future protocols
o+ access to network management functions, such as statistics
o+ access to network debugging functions, such as tracing
In contrast, the naive interface will have:
o+ no access to protocol specific features
o+ no provision for sophisticated event management
o+ potential support for known, existing protocols, but will not
support user access to all protocol features
o+ less coupling to the POSIX I/O routines
Many of the new goals are relevant to both and may be formally adopted
as time permits, but the committee did not discuss how many of the new
goals were also goals for the naive interface. Basically, there wasn't
time.
This is an issue in its own right. Part of the reason for the lack of
time is the need to divide attention between the two interfaces; this
halves the time one would otherwise have for any given topic. The
committee hopes to overcome this problem in time by merging the two
interfaces into one or by dividing the committee into subgroups to
work on the two interfaces in parallel. It is too early to decide
which (if either) tack to take yet; neither interface is well-enough
defined.
2. Methodology
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 4 - IEEE 1003.8 Networking
Someone suggested a top-down approach, for these advantages:
o+ form and order in the production of the standard
o+ avoidance of deadlocks, such as sockets versus XTI
o+ cleaner final design
Favorably disposed to the suggestion, the group informally adopted it.
3. Milestones
Several official milestones were set.
starting the draft 1989
o+ finishing the first draft 1990
o+ mock ballot 1991
o+ full ballot 1992
Earlier dates are possible if more working members can be found to
share the expected workload. (Readers, wake up: this is your chance
to pitch in and help the committee make progress!)
4. Functionality and Objects
The group spent much time presenting and discussing the functionality
and objects for the "naive" and "sophisticated" standards. The lists
generated were rough supersets of the functionality and objects in
XTI, sockets, CNI, and UNI, and are available from Steve Head
(s...@hpda.hp.com) on request. (This has progressed to a skeleton
outline Draft, as of the San Jose meeting!)
The discussions laid a framework for the next tasks before the group:
to separate out specific "sophisticated" from "naive" features, and to
group the functionality and objects in a quasi-language-independent
way. Only after this is done will the group generate C bindings to
the standard.
5. Relationships to Other Organizations
The Chair of P1003.8 made contact with the ISO committees on ISO
protocols. Apparently the rumor that ISO would object to a
transport-level interface on the basis that it is not entering the top
of the ISO stack is unfounded; the chair found no objections among
those he contacted on this issue.
Several parallel efforts at a transport standard were discussed:
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 5 - IEEE 1003.8 Networking
o+ OSF
o+ UI
o+ X/Open XNET's XTI
o+ P1003.4 (real-time) Messages
Steve Head, acting chair of the OSF SIG on Base Communication Services
/ Transport Interfaces Subgroup, sketched OSF status in this area.
Petr Janocek, X/Open XNET chair, described XNET status, and Kathy
Bohrer, leader of the P1003.4 messages working group, gave an overview
of its effort.
Holes in each of these efforts currently prevent the adoption of any
of them as a standard by the group. 1003.8/IPC will address major
networking-specific interface issues left unresolved by other groups,
and will continue to work work on an interprocess communication
standard that is usable, protocol-independent, and well-integrated
with the rest of POSIX.
P1003.4 (real-time) messages were especially controversial. It came
as a surprise to many group members (and, frankly, many other POSIX
members) that 1003.4's charter includes "system extensions". There
seems to be a general feeling that "real-time" is a misleading name,
and 1003.4 may not receive adequate coverage in the balloting
procedure. The group's concern is that this could be a real problem
for extensions that are intended to solve problems involving multiple
nodes in a network. For example, though the message interface is
primarily for real time and generic, messaging-application needs on a
single node, it can also include operation over networks that share
file systems, and enable rendezvousing using the 1003.1 file system
(assuming messages are supported by POSIX Transparent File Access --
which is not at all clear at this time). A file-system name space is
generally inadequate for general network rendezvous purposes,
requiring, as it does, mounts for every possible node, special files
or clone files for every possible endpoint, potentially performance-
and reliability-impacting extensions to the internal file name
resolution routine (e.g., namei() or its equivalent), the adoption of
new, complex protocols to handle requests, and other considerations.
Just as you're unlikely to go into a shoe store if you're looking for
a book, you're unlikely to look in the real-time draft for generic
extensions. Some parts may not have received enough exposure to ensure
functionality and consistency for either typical or special user
application needs. (In any case, the situation will be helped
somewhat by the decision, made in San Jose, that P1003.4 real-time
functions will be balloted as additions to the 1003.1 standard rather
than as a separate standard.)
The committee also worried that several aspects of the 1003.4
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 6 - IEEE 1003.8 Networking
messaging interface seemed redundant or inefficient.
The 1003.4 messages subgroup scheduled a joint meeting with 1003.8 in
July to discuss these problems. In addition, all actively attending
1003.8 working group members were to be placed on the balloting list
for the May, real-time mock ballot.
6. Naming
P1003.8 is forming a "naming" subgroup. The first full meeting of
this group will be at the July meeting.
This group isn't likely to solve the name resolution problem from
scratch (lack of time, not inspiration) so the group may continue to
address it until the naming subcommittee takes over. The group may
decide to meet with them jointly and include them on its balloting
rather than give them a problem they can't ramp up to in time for a
solution. Incidentally there are many name resolution issues, not
just a single problem or single interface likely to solve all
problems.
7. Asynchronous Events
John Barr, the leader of the asynchronous events subgroup, presented
their model of asynchronous event handling to the group. This was
mostly a formality; group members had already been exposed to POSIX
real-time async events handling.
Some concern was raised about select(). Members pointed out that the
real-time draft for async events implied more syscall overhead than
occurs in select() in BSD or poll() in V.3; the real-time group will
resolve the issue, in possible conjunction with the supercomputing
group, which gave us an interesting presentation the "listio()"
routine, which can be used to fire off multiple I/O transfers
operating on a list of file descriptors.
8. XTI versus sockets
The "XTI versus sockets" issue is so important to users and vendors
that it couldn't be left unaddressed. Here is the official committee
consensus:
We make no decision right now on the sophisticated interface's
actual relationship to the existing socket and XTI interfaces,
but it will have a flavor and functionality and granularity
similar to that provided by the socket and XTI interfaces.
In other words, the group feels that there are advantages to both XTI
and sockets, and that POSIX will adopt features from both, but has not
yet addressed whether there will be a straightforward adoption or
direct extension of either, or will take some new form. (One hopes
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 7 - IEEE 1003.8 Networking
that a new form would be a functional superset of the other two.)
The group is quite aware that there are several camps and many
potentially conficting goals in this highly sensitive area. Getting
XTI and socket advocates to agree on a common interface will probably
be a monumental task, fraught with potential dangers and traps. Any
new interface would be likely to need a clear migration path from XTI
and/or sockets to minimize code changes needed for existing
applications: for example, sets of macro routines or public domain
layer routines published in appendices. The group is aware of the
possible precedent set by POSIX 1003.1 with regard to System V and 4.2
BSD (the termios section in particular). The group will study the
potential benefits and drawbacks of all identifiable options before
making any decisions.
The adage that "everyone wants things to get better, but no one wants
anything to change" applies here. The sophisticated interface will
require some compromises. The various camps must realize the benefits
of joining forces and agreeing on a common standard if the working
group is to be successful in this endeavor.
9. e-mail distribution list
The group will use E-mail distribution lists to expedite work and
communication between meetings. The U.C. Berkeley representatives
volunteered to organize this effort and maintain the lists on their
machines.
Anybody may join (or leave) the list by mailing to posix-net-ptp-
request @ucbvax.Berkeley.EDU.
10. Future Agenda
At the San Jose meeting, P1003.8/IPC will:
o+ separate the functionality and objects list into lists for the
"naive" and "sophisticated" interfaces;
o+ obtain (from action items between meetings) a more detailed list
of objects, and a first cut at grouping the functionality and
objects into functions for the two interfaces, and continue work
from that point;
o+ continue to work with P1003.4 on the issues of message interface
and async events
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
Volume-Number: Volume 17, Number 36
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!
apple!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.8 Networking
Message-ID: <406@longway.TIC.COM>
Date: 20 Oct 89 20:28:40 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 386
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
[ I can't seem to find a copy of this in my archives, which probably
means that I neglected to post it with the others in August.
If not, and you've already seen it, please ignore this one. -mod ]
An Update on UNIX* and C Standards Activities
August 1989
Jeffrey S. Haemer, Report Editor
USENIX Standards Watchdog Committee
IEEE 1003.8 Networking Update
Steve Head (s...@hpda.hp.com) reports on the April 1989 meeting:
OVERVIEW
P1003.8 is the IEEE POSIX networking standards committee, working on
network standard interface definitions for POSIX. The committee is
divided into several subcommittees, including transparent file access,
remote procedure call, network IPC, and MAP. There were about 30
attendees at P1003.8 altogether. This is a report on the network IPC
subcommittee, which is creating both a "sophisticated" interface and a
"naive" interface for interprocess communications. Because it is not
yet known whether the group's work will all go into a single standard,
the word "standard" should probably be "standard(s)".
At the April meeting, the group redefined the goals of the two
interfaces, and adopted a top-down methodology to avoid factional
deadlock. It went on to set initial milestones for the end-product
standards, complete a first pass of functionality and objects of
interest, and initiate discussion and cooperation with other
organizations and committees working in related areas.
DETAIL
At this meeting, the main topics of discussion were:
1. Goals
2. Methodology
3. Milestones
4. Functionality and Objects
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 2 - IEEE 1003.8 Networking
5. Relationships to Other Organizations, Standards, and Evolving
Standards
6. Naming
7. Async Events
8. XTI versus sockets
9. e-mail distribution list
10. Future Agenda
Note: in this report, "XTI" refers to X/Open's Transport Interface, a
networking interface definition for UN*X based primarily on AT&T's TLI
(Transport Library Interface). "CNI" refers to the Chemical Abstracts
Company Network Interface, an independently developed transport level
interface which is designed run not only on UN*X but other operating
systems as well. "Sockets" refers to the popular, 4.3-BSD-based
networking interface.
1. Goals
Several new goals were added over the week to the list of existing
goals that had been developed for the sophisticated interface at the
previous meetings.
o+ timeliness of getting the standard to the industry
o+ usability -- the standard must be fully usable, without dangling
dependencies
o+ quality -- not repeat the "mistakes" of predecessors (XTI,
sockets, and CNI)
o+ compatibility -- preserve user investment in existing interfaces
(XTI, sockets, etc.)
In review, the two interfaces share the following goals:
o+ ability to provide client-server support
o+ virtual-circuit- or datagram-level service
o+ accommodate POSIX to non-POSIX datacomm
o+ support for multiple protocol suites and multiple networks in 1
machine
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 3 - IEEE 1003.8 Networking
o+ few "system calls" per logical operation, though the naive
interface will probably be less efficient than the sophisticated
interface
In addition, the sophisticated interface wants:
o+ protocol-independent access to protocol-specific features
o+ sophisticated (POSIX real-time) event management of protocol
interface
o+ provision for support of [existing] protocol-specific features
o+ "clean" feature availability
o+ integration with POSIX I/O routines (read()/write())
o+ easy extensibility to future protocols
o+ access to network management functions, such as statistics
o+ access to network debugging functions, such as tracing
In contrast, the naive interface will have:
o+ no access to protocol specific features
o+ no provision for sophisticated event management
o+ potential support for known, existing protocols, but will not
support user access to all protocol features
o+ less coupling to the POSIX I/O routines
Many of the new goals are relevant to both and may be formally adopted
as time permits, but the committee did not discuss how many of the new
goals were also goals for the naive interface. Basically, there wasn't
time.
This is an issue in its own right. Part of the reason for the lack of
time is the need to divide attention between the two interfaces; this
halves the time one would otherwise have for any given topic. The
committee hopes to overcome this problem in time by merging the two
interfaces into one or by dividing the committee into subgroups to
work on the two interfaces in parallel. It is too early to decide
which (if either) tack to take yet; neither interface is well-enough
defined.
2. Methodology
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 4 - IEEE 1003.8 Networking
Someone suggested a top-down approach, for these advantages:
o+ form and order in the production of the standard
o+ avoidance of deadlocks, such as sockets versus XTI
o+ cleaner final design
Favorably disposed to the suggestion, the group informally adopted it.
3. Milestones
Several official milestones were set.
starting the draft 1989
o+ finishing the first draft 1990
o+ mock ballot 1991
o+ full ballot 1992
Earlier dates are possible if more working members can be found to
share the expected workload. (Readers, wake up: this is your chance
to pitch in and help the committee make progress!)
4. Functionality and Objects
The group spent much time presenting and discussing the functionality
and objects for the "naive" and "sophisticated" standards. The lists
generated were rough supersets of the functionality and objects in
XTI, sockets, CNI, and UNI, and are available from Steve Head
(s...@hpda.hp.com) on request. (This has progressed to a skeleton
outline Draft, as of the San Jose meeting!)
The discussions laid a framework for the next tasks before the group:
to separate out specific "sophisticated" from "naive" features, and to
group the functionality and objects in a quasi-language-independent
way. Only after this is done will the group generate C bindings to
the standard.
5. Relationships to Other Organizations
The Chair of P1003.8 made contact with the ISO committees on ISO
protocols. Apparently the rumor that ISO would object to a
transport-level interface on the basis that it is not entering the top
of the ISO stack is unfounded; the chair found no objections among
those he contacted on this issue.
Several parallel efforts at a transport standard were discussed:
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 5 - IEEE 1003.8 Networking
o+ OSF
o+ UI
o+ X/Open XNET's XTI
o+ P1003.4 (real-time) Messages
Steve Head, acting chair of the OSF SIG on Base Communication Services
/ Transport Interfaces Subgroup, sketched OSF status in this area.
Petr Janocek, X/Open XNET chair, described XNET status, and Kathy
Bohrer, leader of the P1003.4 messages working group, gave an overview
of its effort.
Holes in each of these efforts currently prevent the adoption of any
of them as a standard by the group. 1003.8/IPC will address major
networking-specific interface issues left unresolved by other groups,
and will continue to work work on an interprocess communication
standard that is usable, protocol-independent, and well-integrated
with the rest of POSIX.
P1003.4 (real-time) messages were especially controversial. It came
as a surprise to many group members (and, frankly, many other POSIX
members) that 1003.4's charter includes "system extensions". There
seems to be a general feeling that "real-time" is a misleading name,
and 1003.4 may not receive adequate coverage in the balloting
procedure. The group's concern is that this could be a real problem
for extensions that are intended to solve problems involving multiple
nodes in a network. For example, though the message interface is
primarily for real time and generic, messaging-application needs on a
single node, it can also include operation over networks that share
file systems, and enable rendezvousing using the 1003.1 file system
(assuming messages are supported by POSIX Transparent File Access --
which is not at all clear at this time). A file-system name space is
generally inadequate for general network rendezvous purposes,
requiring, as it does, mounts for every possible node, special files
or clone files for every possible endpoint, potentially performance-
and reliability-impacting extensions to the internal file name
resolution routine (e.g., namei() or its equivalent), the adoption of
new, complex protocols to handle requests, and other considerations.
Just as you're unlikely to go into a shoe store if you're looking for
a book, you're unlikely to look in the real-time draft for generic
extensions. Some parts may not have received enough exposure to ensure
functionality and consistency for either typical or special user
application needs. (In any case, the situation will be helped
somewhat by the decision, made in San Jose, that P1003.4 real-time
functions will be balloted as additions to the 1003.1 standard rather
than as a separate standard.)
The committee also worried that several aspects of the 1003.4
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 6 - IEEE 1003.8 Networking
messaging interface seemed redundant or inefficient.
The 1003.4 messages subgroup scheduled a joint meeting with 1003.8 in
July to discuss these problems. In addition, all actively attending
1003.8 working group members were to be placed on the balloting list
for the May, real-time mock ballot.
6. Naming
P1003.8 is forming a "naming" subgroup. The first full meeting of
this group will be at the July meeting.
This group isn't likely to solve the name resolution problem from
scratch (lack of time, not inspiration) so the group may continue to
address it until the naming subcommittee takes over. The group may
decide to meet with them jointly and include them on its balloting
rather than give them a problem they can't ramp up to in time for a
solution. Incidentally there are many name resolution issues, not
just a single problem or single interface likely to solve all
problems.
7. Asynchronous Events
John Barr, the leader of the asynchronous events subgroup, presented
their model of asynchronous event handling to the group. This was
mostly a formality; group members had already been exposed to POSIX
real-time async events handling.
Some concern was raised about select(). Members pointed out that the
real-time draft for async events implied more syscall overhead than
occurs in select() in BSD or poll() in V.3; the real-time group will
resolve the issue, in possible conjunction with the supercomputing
group, which gave us an interesting presentation the "listio()"
routine, which can be used to fire off multiple I/O transfers
operating on a list of file descriptors.
8. XTI versus sockets
The "XTI versus sockets" issue is so important to users and vendors
that it couldn't be left unaddressed. Here is the official committee
consensus:
We make no decision right now on the sophisticated interface's
actual relationship to the existing socket and XTI interfaces,
but it will have a flavor and functionality and granularity
similar to that provided by the socket and XTI interfaces.
In other words, the group feels that there are advantages to both XTI
and sockets, and that POSIX will adopt features from both, but has not
yet addressed whether there will be a straightforward adoption or
direct extension of either, or will take some new form. (One hopes
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
August 1989 Standards Update - 7 - IEEE 1003.8 Networking
that a new form would be a functional superset of the other two.)
The group is quite aware that there are several camps and many
potentially conficting goals in this highly sensitive area. Getting
XTI and socket advocates to agree on a common interface will probably
be a monumental task, fraught with potential dangers and traps. Any
new interface would be likely to need a clear migration path from XTI
and/or sockets to minimize code changes needed for existing
applications: for example, sets of macro routines or public domain
layer routines published in appendices. The group is aware of the
possible precedent set by POSIX 1003.1 with regard to System V and 4.2
BSD (the termios section in particular). The group will study the
potential benefits and drawbacks of all identifiable options before
making any decisions.
The adage that "everyone wants things to get better, but no one wants
anything to change" applies here. The sophisticated interface will
require some compromises. The various camps must realize the benefits
of joining forces and agreeing on a common standard if the working
group is to be successful in this endeavor.
9. e-mail distribution list
The group will use E-mail distribution lists to expedite work and
communication between meetings. The U.C. Berkeley representatives
volunteered to organize this effort and maintain the lists on their
machines.
Anybody may join (or leave) the list by mailing to posix-net-ptp-
request @ucbvax.Berkeley.EDU.
10. Future Agenda
At the San Jose meeting, P1003.8/IPC will:
o+ separate the functionality and objects list into lists for the
"naive" and "sophisticated" interfaces;
o+ obtain (from action items between meetings) a more detailed list
of objects, and a first cut at grouping the functionality and
objects into functions for the two interfaces, and continue work
from that point;
o+ continue to work with P1003.4 on the issues of message interface
and async events
Jeffrey S. Haemer, Editor USENIX Standards Watchdog Committee
Volume-Number: Volume 17, Number 36
|