Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 1: Overview
Message-ID: <333@longway.TIC.COM>
Date: 22 Apr 89 19:25:17 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 73
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
An update on UNIX|= Standards Activities - Part 1
Overview
February 20, 1989
Shane P. McCarron, NAPS International
This marks the fifth in a series of articles about the Unix
Standards community. Before we get too far here, I would
like to apologize for the lateness of this particular
report. While it should have been out in mid-February, it
is now late March and I am just completing the editing.
Hopefully this type of delay will not be seen again.
THe big news this quarter is that the ANSI C Standard
X3.159-1989 has been approved by the X3 Secretariat. This
means that the X3 people are satisfied with the technical
merit of the standard, as well as with the procedures that
were followed in completing it. Once it has been formally
reviewed by ANSI, we will have an American National standard
for the C language. This is good and bad. The C Language
standard has a few glaring flaw that make it all but
impossible to write a truly portable application. I am
certain that it is possible to write a mostly portable
application with little difficulty, but that wasn't really
the goal of the standard. More on this later.
This quarter we have reports from a number of committees.
They are in various states of repair, with varying levels of
detail. I have received little feedback from you about how
much detail should be included in the reports.
Consequently, it has been left up to the Usenix Watchdog
Committee contacts to generate as much or as little material
as they see fit. If you have comments on this, please send
them to me or directly to the contact person whose report
you are commenting on.
As always, we are looking for a few good people to represent
us in standards committees. If you would like to work with
us in trying to bring the world of standards to light,
please contact the Standards Watchdog Committee's Volunteer
Coordinator, Marc Teitelbaum < m...@okeeffe.berkeley.edu>.
__________
|= UNIX is a registered trademark of AT&T in the U.S. and
other countries.
- 2 -
Please look to the subsequent postings in this series for
all of the reports. If you have any comments or
suggestions, please contact me at:
Shane P. McCarron
NAPS International
117 Mackubin St.
Suite 6
St. Paul, MN 55102
+1 (612) 224-9239
a...@bungia.mn.org
uunet!bungia.mn.org!ahby
Publisher's note: Shane has moved and taken a new job.
We are currently looking for a new report editor.
Interested applicants please send electronic mail to
j...@usenix.org or talk to Marc Teitelbaum at the IEEE 1003
meeting in Minneapolis, 24-28 April. -John S. Quarterman
Volume-Number: Volume 16, Number 31
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!
longway!std-unix
From: a...@bungia.mn.org (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 2: IEEE 1003.0
Message-ID: <334@longway.TIC.COM>
Date: 23 Apr 89 02:31:16 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Lines: 91
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
From: Shane P. McCarron < a...@bungia.mn.org>
An update on UNIX|= Standards Activities - Part 2
IEEE 1003.0
February 20, 1989
Shane P. McCarron, NAPS International
1003.0 - POSIX Guide
The following report is printed exactly as it was sent to me
by our contact in 1003.0. I find his unedited observations
to be very enlightening.
This past Jan 89 meeting for IEEE 1003.0 group is the fourth
since the group's inception. The first took place in March
1988. In summary, it has been a bit of a roller coaster
ride. We jumped into the fray back in March with high
expectations and with the strong intentions of having taken
bold steps by now. Upon coming up to our one year mark, it
is clear to me that we have been (and still are)
experiencing a rite of passage. Specifically, we have gone
through the growing pains that every volunteer organization
does when attempting to take bold strides, only to stumble
on such things as consensus, priorities, level of detail,
and parameters.
It also clear to me that this was inevitable. Given the
state of affairs within this whole realm of open systems,
i.e. contention and conflict, and given the goal of our
attempting to address this realm (to which no accredited
body has addressed itself to date), conflict and a bit of
thrashing around were, in retrospect, to be expected. The
group is reaching the point where a significant amount of
synergy is developing. I would define that as everyone
knowing what to expect from those who are the most vocal AND
each person knowing when to limit and/or categorize his/her
discussion.
We struggled with procedural issues in order to ensure that
anarchy did not reign while concurrently ensuring that
creativity was not stifled. We are beginning to reach this
goal.
We experienced the classic problem of everyone during a
meeting setting high and lofty goals only for things to fall
through the cracks when they returned to their jobs and saw
other pressing priorities awaiting them. Goals set during
this past meeting were more pragmatic and better thought
out. In addition, the group's leadership is taking a more
active role to ensure that friendly reminders and follow ups
occur. (I thought I heard someone say that their legs might
be broken if action items were missed but I was outside
getting a cup of tea at the time.)
One very key and contentious issue which was discussed and
tabled was that of changing our PAR to say that we will
develop a standard instead of a guide. This kind of change
has far-reaching ramifications and, in my strong opinion, is
unwise and unneeded. Some felt it was necessary to put some
"teeth" into our end-product by making it a standard. So
much attention is being paid to our effort now that a basic
list of priority standards would garner significant
consumption. And we are certainly proceeding further than
that.
Overall, the group is coming together and a second draft
version is in the works. (Draft 1 was, for the most part, an
outline). The goal for our April meeting is to have a draft
that the group feels is mature enough to begin invoking the
formal proposal process for future changes. We'll have to
wait and see what these next few months yield.
The USENIX Standards Watchdog Committee contact for 1003.0
is Kevin Lewis. He can be reached at:
Kevin Lewis
DEC
1331 Pennsylvania Avenue NW
Suite 645
Washington, DC 20004
kle...@gucci.dec.com
+1 (202) 383-5633
Volume-Number: Volume 16, Number 32
Path: utzoo!attcan!uunet!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update Part 3: 1003.4
Message-ID: <336@longway.TIC.COM>
Date: 11 May 89 15:37:35 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 85
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
Standards Update Part 3: 1003.4
An update on UNIX|= Standards Activities
January 1989 IEEE 1003 Meeting, Ft. Lauderdale
Part 3: 1003.4
Shane P. McCarron, NAPS International
1003.4 - Real Time Extensions to POSIX
In the previous report, I reported that the Real-Time
committee was prepared to start mock ballot procedures after
the January meeting. For those of you who have just tuned
in, a mock ballot is a review process where IEEE formal
ballot rules are used, but the ballot is not conducted by
the IEEE Standards Office. It is used by some committees as
a means of testing to see whether their draft is ready for
prime time. Anyway, it appears that there were a few
problems that came up at the last minute, and the
anticipated mock ballot did not happen.
The main reason for this is that two important
proposals have not reached full concensus within the
committee - Realtime Files and Process Memory Locking. The
working group felt that these were a little too rough for a
formal review, so an extra three months was taken to get
them into better condition. The April meeting should
produce a draft for mock ballot.
Those two issues that prevented the draft from going to
mock ballot also proved to be the most controversial yet.
There was a heated debate about the realtime files proposal
because some people wanted parts of the proposal to be
mandatory for all implementations. The proposal would
require all conforming implementations to implement an
Extent Based File System (Among the attributes of an EBFS is
the ability to allocate a file in physically contigous
chunks). This issue went around the table several times but
no final resolution was reached. The next meeting will
(hopefully) complete these debates.
The memory locking proposal was reworked to allow an
implementation that does not "stack" user requests. In the
original proposal, the user was allowed to stack locks. The
system was required to maintain information about each byte
__________
|= UNIX is a registered trademark of AT&T in the U.S. and
other countries.
January 1989 - 1 - Ft. Lauderdale
Standards Update Part 3: 1003.4
and the number of times the user locked that byte in memory.
The draft 6 proposal will be much simpler then the one
released with draft 5.
The committee also examined what future topics should
be covered. First on the list is a threads (or light weight
process) mechanism. The realtime committee will be
addressing this issue directly after the first draft is
finished (or before if some working group members get their
way). There are currently a number of unique interfaces to
threads, and selecting one for a standard should prove to be
a major challenge.
The USENIX Standards Watchdog Committee contact for
1003.4 is Sol Kavy. He can be reached at:
Sol Kavy
Hewlett-Packard
19477 Pruneridge
Cupertino, CA 95014
s...@hpda.hp.com
hpda!sol
+1 (408) 477-6395
January 1989 - 2 - Ft. Lauderdale
Volume-Number: Volume 16, Number 34
Path: utzoo!attcan!uunet!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update Part 4: 1003.5
Message-ID: <337@longway.TIC.COM>
Date: 11 May 89 15:38:43 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 238
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
Standards Update Part 4: 1003.5
An update on UNIX|= Standards Activities
January 1989 IEEE 1003 Meeting, Ft. Lauderdale
Part 4: 1003.5
Shane P. McCarron, NAPS International
1003.5 - Ada Bindings to POSIX
This quarter's 1003.5 report points out some problems
that are really endemic to the entire standards making
process. To wit, the people involved in making standards
are rarely those who end up using them. The user community
does not (generally) have the wherewithal or time to join
standards committees and attend standards committee
meetings. POSIX, like all other standards, suffers from
this problem.
In the case of 1003.5, the problem manifests itself in
a new way. While there are few members of the committee,
the vendor and end user community are about evenly
represented. This would seem to be an advantage.
Unfortunately, the Ada vendor and user community is not a
UNIX oriented community. The members of this committee,
while very knowledgeable about Ada and its requirements, may
not be as well verse in traditional UNIX semantics as one
would like.
This may change as the DoD (and the entire US Federal
Government) becomes more interested in POSIX. Until that
time, 1003.5 is going to suffer from a dearth of UNIX
oriented members. This may cause them to produce a standard
that, while strong in Ada terms, is weak when it comes to
its relationship to POSIX based systems.
The Ada language binding group has a goal of having a
standard Ada binding for P1003.1 by the end of 1989, with
balloting to take place some time in the fall. The first
draft of this standard was available for the January meeting
of the POSIX committees, and it is going to take quite a bit
of work to get it ready for a fall ballot. This committee
is really in desparate need of some warm bodies - preferably
with Ada and UNIX backgrounds.
__________
|= UNIX is a registered trademark of AT&T in the U.S. and
other countries.
January 1989 - 1 - Ft. Lauderdale
Standards Update Part 4: 1003.5
In addition, they need Ada real-time experts to review
the P1003.4 (real-time extensions) draft. 1003.5 will
eventually be producing a binding to that standard as well,
and it is imperative that all of the semantics that Ada
requires of real-time extensions be available. The 1003.4
working group has actually requested that 1003.5 generate
responses to some proposals they are considering, but right
now they do not have enough people to complete their own
work.
At the January meeting, the working group started
reviewing (and changing) the first draft of the standard, as
well as reorganizing their concepts of how POSIX related
functions could be grouped logically into Ada packages.
The group decided to map POSIX signals onto Ada task
entries, following the semantic model established by the Ada
standard for interrupts. The discussion narrowed down to
three proposals for the way in which a user would express
the binding of signal to entry. One major issue is whether
it is sufficient for this binding to be specified entirely
statically, at compile-time, or whether users will need to
be able to rebind dynamically. In the traditional C/UNIX
world, rebinding of signals to signal handling functions is
used frequently. The other issue was whether signal should
only be handleable by tasks of a very simple (generic)
form,that handles only one signal, or whether any task
should be allowed to have signal-handling entries.
The group decided that, from the point of view of the
Ada binding, each Ada program execution would consist of a
single POSIX process. Implementations might make use of
multiple processes at some lower level, but this would not
be visible from the POSIX interface. This does not say that
a program may not fork, but that the result of a fork
operation would be another program execution, rather than
another thread (read process, task, etc.) within the same
program execution. This has the effect of simplifying the
problems presented by signals as well as SUSPEND, RESUME,
PAUSE, etc.
Perhaps the most interesting issues to come out at the
meeting did not involve the draft document directly, but
were more global in nature, coming up in combined meetings
with other groups.
A meeting with the P1003.1 group that is working on the
language-independent version of the standard (required by
ISO) revealed that the Ada binding group may have been
taking too conservative a view with repect to following the
C version of the P1003.1 standard. As things evolve, it is
January 1989 - 2 - Ft. Lauderdale
Standards Update Part 4: 1003.5
acceptable that conformant Ada-POSIX implementations may be
incapable of supporting C-POSIX, and vice versa. That is,
the language-independent binding will be very abstract.
There is no such thing as a POSIX interface without a
language binding. Specific language bindings may provide or
require functionality not provided by other language
bindings. For example, an Ada binding need not directly
provide the present POSIX I/O operations. It is appropriate
to simply provide the Ada I/O and explain the relationship
to POSIX I/O. Similarly an Ada binding might impose
additional requirements on system calls to insure correct
operation in the presence of multiple threads of control
within a process.
This may encourage P1003.5 to be bolder, but there
remains concern that since the Ada binding is in many
instances likely to be implemented "on top" of a C binding,
it must not force the Ada programmer to sacrifice any
important capabilities, or he will be encouraged to
interface directly to the C binding. For the same reason,
it is impractical to impose requirements that cannot be
implemented via interface to the C binding.
Some very vocal members of the P1003.5 group complained
bitterly that P1003.1 should provide a memory allocation
primitive. (Providing functionality of "sbrk" on some
systems, or "malloc" in C.) There are two reasons for this:
(1) to implement the Ada "new" allocator; (2) to allow a
user to implement his own (more predictable) storage
manager, in a portable way. The latter is viewed as
important by many Ada users, who are concerned that the Ada
language standard does not require an adequate storage
allocation and recovery scheme for all applications.
Interestingly, the FORTRAN language binding group, which was
also in on this discussion, felt the same way, also for
reason (2). The position of P1003.1 was hard-line: memory-
management is a language implementation function, out of
scope of the the POSIX interface.
This memory allocation issue came up at an evening
meeting with the P1003.4 (Real-time Extensions) working
group, with the same position being voiced by P1003.1
representatives. However, P1003.4 members pointed out that
they will have an allocation mechanism for shared memory, so
that a user could work around the lack of a local memory
allocation primitive by using shared memory! (If there is
no bread, let them eat cake?)
The main reason for the P1003.4/5 meeting was to
discuss the issue of multiple threads of control within a
process (a.k.a. lightweight processes). Ada runtime system
January 1989 - 3 - Ft. Lauderdale
Standards Update Part 4: 1003.5
implementors are concerned because they must provide this
capability (tasks), and some existing UNIX implementations
do not allow this to be done in a satisfactory way. POSIX
does not address this problem, and there is no plan to
address it in the near future (< 2 years).
The memory allocation and multithread issues are part
of a more general issue, concerning the scope of POSIX as an
end-user application-layer interface, versus an interface
that might be useful to language implementors. Ada language
and runtime-system implementors would like a POSIX interface
sufficiently well defined that their code-generators and
runtime systems need not be concerned with details specific
to a particular POSIX implementation (beyond the underlying
hardware architecture). This is especially true about the
implementation of Ada tasking, dynamic storage management,
and certain standard packages like the IO packages and
Calendar. That is, it would be nice to know that every
POSIX implementation would provide the primitives needed to
implement Ada.
The official (and majority) position on this issue is
very clear, though a few vocal individuals remain unhappy
with it. Support for language implementations is beyond the
scope of POSIX. Ada language implementations will need to
make use nonstandard features of particular POSIX
implementations.
Another interface issue that is of concern to some Ada
POSIX group is language interoperability, to the extent of
supporting procedure calls from Ada to C, and the ability of
Ada programs to read POSIX character files produced by C
programs using POSIX I/O, and vice versa. The resolution of
this issue is that POSIX will be language-independent, but
will not address language interoperability. For example,
converting between POSIX strings and Ada strings is an
interoperability problem. An Ada binding would simply use
Ada strings.
The P1003.5 group will exchange proposals by net-mail
and meet again with the full POSIX group at the April 1003
meeting in Minneapolis. We will probably have a mock ballot
prior to July to be resolved at the July meeting, in San
Francisco. The official ballot should immediately follow so
that resolution can occur at the October meeting.
The USENIX Standards Watchdog Committee contact for
1003.5 is Ted Baker. He can be reached at:
Ted Baker
Department of Computer Science
January 1989 - 4 - Ft. Lauderdale
Standards Update Part 4: 1003.5
Florida State University
Tallahassee, FL 32306
+1 904 644-5452
tba...@ajpo.sei.cmu.edu
b...@nu.cs.fsu.edu
January 1989 - 5 - Ft. Lauderdale
Volume-Number: Volume 16, Number 35
Path: utzoo!attcan!uunet!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update Part 6: 1003.7
Message-ID: <339@longway.TIC.COM>
Date: 11 May 89 15:41:03 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 189
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
Standards Update Part 6: 1003.7
An update on UNIX|= Standards Activities
January 1989 IEEE 1003 Meeting, Ft. Lauderdale
Part 6: 1003.7
Shane P. McCarron, NAPS International
1003.7 - System Administration
At the first official meeting of the 1003.7 working
group, John Quarterman presented a USENIX concern about the
direction that the working group seemed to be taking.
USENIX was concerned about the "single machine" model which
was being suggested by the working group for designing tools
and utilities. USENIX felt that if a single machine model
where used, it would be difficult or impossible to extend
the utilities and interfaces adopted by the committee to a
networked system. However, if the working group chose a
model in which a machine was assumed to be part of a tightly
coupled network, then a single stand-alone machine could be
a simple special case of a networked machine.
After some deliberation, the working group adopted the
USENIX model of a machine in a tightly coupled network.
This has some rather far-reaching implications on the
direction of the working group, as it is a different
approach than that taken by 1003.1 and 1003.2. It will also
mean that the group will be relying heavily on work and
expertise from 1003.8 (networking). It also means that some
of the concepts, such as a filesystem, which we thought we
had a definition for, suddenly become much more complex.
In addition, it means that the working group will be
reviewing several documents which reflect prior art in the
area of networking, such as the CMIP, ASN.1 and SMNP
networking protocols. These protocols will be reviewed at
the next meeting.
A number of areas are affected by networking
implications. Some of these are difficult to resolve, since
things like device management, print spooling and
performance monitoring, to name a few, may want to cross a
network. The working group is still undecided about the
direction which is going to be taken here. The two obvious
__________
|= UNIX is a registered trademark of AT&T in the U.S. and
other countries.
January 1989 - 1 - Ft. Lauderdale
Standards Update Part 6: 1003.7
options are to provide for centralized administration of a
network of machines, allocating and deallocating devices
over the network from central spot; or a decentralized model
in which each machine in responsible for administering the
devices connected to it. This will be reviewed at the next
meeting.
Although this was our first meeting, a substantial
amount of work was done by the working group. The first two
days were spent reviewing global issues to the working
group, such as determining direction, reviewing IEEE
procedures, discussion of previous informal meetings of the
system administration group and discussion of which model to
choose. Once all of this was done, the working group split
up into small groups and focused on the areas which needed
to be addressed. Specifically, the areas being addressed
are:
1. Process Management
2. Spooling Management
3. System Startup/Shutdown
4. Communication Management
5. File Systems Management
6. Performance Monitoring
7. System Accounting
8. Device and Media Management
9. Software Management
10. User Administration
11. System Monitoring
12. Miscellaneous
13. Introduction
Some items of note:
Spooling Management
The System V spooling mechanism was chosen as a model
for the working group. This model has been adopted by
X/Open. It was recognized by the working group that the
January 1989 - 2 - Ft. Lauderdale
Standards Update Part 6: 1003.7
current System V lp interface does not adequately support
networking. The working group felt that it could be extended
to support networking relatively easily.
Communications Management
The committee will review the CMIP, ASN.1 and SMNP
protocols to determine if and how these protocols may fit
into the work that the working group is doing. In addition,
UUCP managed to rear it's (useful but ugly) head here. Even
though 1003.2 has parts of UUCP within its scope, this
committee may need to address the issues of UUCP
administration.
File System Management
The biggest problem here will be defining what a file
system really is. 1003.7 will be looking to 1003.8 for help
in defining the concept. However, the group has realized
that even without a definition it will be useful to be able
to mount, unmount and check file systems.
Performance Monitoring
The performance monitoring group has followed the lead
of the /usr/group performance monitoring committee. This is
hardly surprising considering that the technical reviewer
for this section is the chair of the /usr/group performance
monitoring committee. Their model seems reasonable, and in
fact represents prior work in this area.
System Installation
An inordinate amount of time was spent drafting an
objection to the AIU facility described in 1003.2. The
object will be submitted to 1003.2 as an objection from the
1003.7 working group. There are a number of concerns about
the application installation which many in the working group
and outside of it feel are not able to be addressed by a
rigidly-defined installation utility. Work progresses in
spite of these concerns.
The working group submitted a substantial amount of
work to the technical editors. The editors have now
collated all of this information and produced a draft that
will be discussed at tha April meeting. Although this
document may not be suitable for release, it will at least
provide a framework for development for the working group.
Obviously, the work has just begun, but so far a fair
amount of progress has been made, and hopefully, more
January 1989 - 3 - Ft. Lauderdale
Standards Update Part 6: 1003.7
progress will be made in future meetings.
The USENIX Standards Watchdog Committee contact on
1003.7 is Mark Colburn. He can be reached at:
Mark Colburn
Minnetech Consulting, Inc.
117 Mackubin St.
Suite 1
St. Paul, MN 55102
(612) 224-9108
m...@jhereg.mn.org
January 1989 - 4 - Ft. Lauderdale
Volume-Number: Volume 16, Number 37
|