Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/reports/1989.05

Text File | 1989-08-11 | 49.4 KB | 1,282 lines

echo 89.05.overview
cat >89.05.overview <<'shar.89.05.overview.4632'
From root  Sat Apr 22 14:31:23 1989
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 1: Overview
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 22 Apr 89 19:25:17 GMT
Apparently-To: std-unix-archive


      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 <[e-mail]>.

__________

  |= 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
          [phone]
          [e-mail]
          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
[e-mail] or talk to Marc Teitelbaum at the IEEE 1003
meeting in Minneapolis, 24-28 April.  -John S. Quarterman

Volume-Number: Volume 16, Number 31

shar.89.05.overview.4632
echo 89.05.over.a
cat >89.05.over.a <<'shar.89.05.over.a.4632'
From root  Mon Apr 24 12:01:44 1989
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Part 1: Overview
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: uunet!BRL.MIL!gwyn
Date: 23 Apr 89 01:01:19 GMT
Apparently-To: std-unix-archive

Newsgroups: comp.std.unix
From: uunet!BRL.MIL!gwyn

> 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 so-called information is completely misleading and certainly
did NOT come from the "X3J11 watchdog" (me).

The proposed ANS for the C programming language was approved by
letter ballot at the X3 level, but a public comment letter turned
up that had been misplaced by the X3 Secretariat, necessitating
further consideration by X3J11 and a possible additional X3 ballot
(if the correspondent feels that his issues were not adequately
addressed by X3J11 and formally submits remarks to that effect to
X3).  Until we get past this stage (which will require up to six
more weeks, depending on events), the proposed standard will not
be submitted to ANSI for ratification.

The good news is that ISO WG14 has agreed to support the proposed
ANS for C with no modifications as the ISO standard also.  (This
agreement was linked to a guarantee from X3J11 that BSI concerns
about identifying further specific instances of implementation-
dependent behavior would be addressed early in the post-standard
"interpretations" phase.)

As to "glaring flaws", I am aware of no such thing.  It is quite
easy to write a maximally portable application in Standard C.
I don't know what Shane thinks the problem is, but I reported
nothing of the kind and totally repudiate his pronouncement.

    - Douglas A. Gwyn

Volume-Number: Volume 16, Number 33

shar.89.05.over.a.4632
echo 89.05.1003.0
cat >89.05.1003.0 <<'shar.89.05.1003.0.4632'
From root  Sat Apr 22 21:31:22 1989
From: Shane P. McCarron <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, Part 2: IEEE 1003.0
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 23 Apr 89 02:31:16 GMT
Apparently-To: std-unix-archive

From: Shane P. McCarron <[e-mail]>

      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
          [e-mail]
          [phone]


Volume-Number: Volume 16, Number 32

shar.89.05.1003.0.4632
echo 89.05.1003.4
cat >89.05.1003.4 <<'shar.89.05.1003.4.4632'
From root  Thu May 11 12:26:21 1989
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update Part 3: 1003.4
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 11 May 89 15:37:35 GMT
Apparently-To: std-unix-archive

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
          [e-mail]
          hpda!sol
          [phone]

January 1989               - 2 -              Ft. Lauderdale


Volume-Number: Volume 16, Number 34

shar.89.05.1003.4.4632
echo 89.05.1003.4.a
cat >89.05.1003.4.a <<'shar.89.05.1003.4.a.4632'
From root  Sun May 14 17:25:54 1989
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Sol Kavy's snail address
Message-Id: <[e-mail]>
Reply-To: Dave Decot <uunet!hpda!decot>
Date: 12 May 89 17:51:54 GMT
Apparently-To: std-unix-archive

From: Dave Decot <uunet!hpda!decot>

The physical mail address given for Sol Kavy (the USENIX Watchdog for 1003.4)
should have included his mail stop.  Without a mailstop, mail can take up to
twice as long to reach an HP employee.

Please add:

   Mail Stop 47UX

to the mail address when corresponding with Sol by physical mail.


Dave Decot
Hewlett-Packard
[e-mail]

Volume-Number: Volume 16, Number 39

shar.89.05.1003.4.a.4632
echo 89.05.1003.5
cat >89.05.1003.5 <<'shar.89.05.1003.5.4632'
From root  Thu May 11 12:30:12 1989
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update Part 4: 1003.5
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 11 May 89 15:38:43 GMT
Apparently-To: std-unix-archive


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
          [phone]
          [e-mail]
          [e-mail]

January 1989               - 5 -              Ft. Lauderdale


Volume-Number: Volume 16, Number 35

shar.89.05.1003.5.4632
echo 89.05.1003.5.a
cat >89.05.1003.5.a <<'shar.89.05.1003.5.a.4632'
From root  Wed May 17 14:21:30 1989
From: David E. Emery <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update Part 4: 1003.5
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (David E. Emery)
Date: 15 May 89 18:14:41 GMT
Apparently-To: std-unix-archive

Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: [e-mail]
Return-Path: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
From: [e-mail] (David E. Emery)

    Standards Update                              Part 4: 1003.5

              An update on UNIX|= Standards Activities
           January 1989 IEEE 1003 Meeting, Ft. Lauderdale


         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.

---------------
I don't think this is a very fair characterization of our working
group.  It may have been true at Minneapolis (where most of the 1003.5
officers, for various reasons, were unable to attend), but many of us
have a pretty solid Unix background.  It is true that we sometimes
have to educate the 'uninitiated'.  It is also true that we need more
bodies, particularly people literate in both Unix and Ada.  However,
there is a substantial interest in Ada on Unix, indicated by the large
number of vendors (Verdix, Telesoft, Alsys, Meridian, DDC and Tartan
Labs <this list is probably not complete, either>).

However, I take significant exception to the implication that the
1003.5 committee "does not understand Unix."  This is particularly
true when you look at the expressed attitude of the rest of 1003, that
"we don't care about Ada", or at best "we don't have time to learn
Ada".  We have a major problem when Ada and Unix clash, a problem I
don't think that the rest of P1003 can appreciate (given their narrow
C focus).

                dave
                [e-mail]

[ The report was based on the Minneapolis meeting.
It's good to see some counter opinions, though.  -mod ]

Volume-Number: Volume 16, Number 41

shar.89.05.1003.5.a.4632
echo 89.05.1003.5.b
cat >89.05.1003.5.b <<'shar.89.05.1003.5.b.4632'
From news  Thu May 18 04:14:43 1989
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: POSIX flame...
Message-Id: <[e-mail]>
References: <[e-mail]>;
Reply-To: uunet!uiunix!ahby (Shane McCarron)
Date: 16 May 89 18:48:31 GMT
Apparently-To: std-unix-archive

To: [e-mail] (David E. Emery)
Cc: std-unix, [e-mail]
From: uunet!uiunix!ahby (Shane McCarron)

> However, I take significant exception to the implication that the
> 1003.5 committee "does not understand Unix."  This is particularly
> true when you look at the expressed attitude of the rest of 1003, that
> "we don't care about Ada", or at best "we don't have time to learn
> Ada".  We have a major problem when Ada and Unix clash, a problem I
> don't think that the rest of P1003 can appreciate (given their narrow
> C focus).

I guess that I may have said something a little strong here.  However,
I am not ready to retract the statement.  There were many people at
the Minneapolis meeting last fall who were not at all aquainted with
the semantics of fundamental parts of Unix.  As an example, I would
point to the misconception (by all of the group, if I remember
correctly) that if you call getcwd() with a NULL pointer, and then
later changed directories with a chdir(), then the string pointed to
by that previous call would be replaced by the new pathname!  This is
hardly a full understanding.

So, while I believe that the Ada vendor community is fully behind
getting Ada on Unix, I am not convinced that the expertise is in the
committee to completely specify the interfaces.  Fortunately, now that 1003.5
is meeting in conjunction with the rest of the POSIX committees, there is
good possibility of liaison and consultation.  That should result in a
better, more complete specification.  Couple that with the intent of
1003.5 to go to mock ballot soon, which will get their document much
more exposure, and you have a very promising view of the future.

I would also like to address the comment about an apparent lack of interest
in Ada by the other POSIX committees.  You're right.  That's the nicest
way to say it.  Why?  Because the C programmers of the world (many of
them) don't take Ada seriously.  As such, they are probably being
unjust.  Until they realize that Ada is a real power in the future of
programming, they are not going to take it seriously.  This has
resulted, unfortunately, in the rest of the POSIX committee members
not really looking too closely at the Ada effort.  This is a mistake,
there is no excuse for it, but that's just the way it is.
--
Shane P. McCarron            ATT:    [phone]
Project Manager                UUCP:    [e-mail]

Volume-Number: Volume 16, Number 42

shar.89.05.1003.5.b.4632
echo 89.05.1003.5.c
cat >89.05.1003.5.c <<'shar.89.05.1003.5.c.4632'
From news  Thu May 18 04:20:52 1989
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: POSIX flame...
Message-Id: <[e-mail]>
Reply-To: uunet!aries.mitre.org!emery (David Emery)
Date: 17 May 89 13:59:08 GMT
Apparently-To: std-unix-archive

Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: [e-mail]
Cc: std-unix, [e-mail], [e-mail]
From: uunet!aries.mitre.org!emery (David Emery)

Shane writes:
>I guess that I may have said something a little strong here.  However,
>I am not ready to retract the statement.  There were many people at
>the Minneapolis meeting last fall who were not at all aquainted with
>the semantics of fundamental parts of Unix.  As an example, I would
>point to the misconception (by all of the group, if I remember
>correctly) that if you call getcwd() with a NULL pointer, and then
>later changed directories with a chdir(), then the string pointed to
>by that previous call would be replaced by the new pathname!  This is
>hardly a full understanding.

I don't remember this incident, and I was in Minneapolis last fall.  I
do know that there are places in 1003.1 (but getcwd() is NOT one of
them) where sometimes a call returns the address of memory which is
subject to change (i.e. memory inside the kernal, or whatever).  This
causes us major fits with respect to tasking, so we discussed how to
prevent/avoid/remove this problem.  I also remember some discussions
concerning the behavior of POSIX (not Unix) when NULL was passed as a
parameter to some routines.  This was often (particularly in Draft 12)
not well specified, even as being undefined.  (Incidently, calling
getcwd with a NULL pointer is clearly stated as being undefined in
1003.1 Drafts 12 and 13.)

We in the Ada community (regardless of Unix-literacy) have a heluva
lot more experience with formal standards documents than the Unix
community.  Consider how most people learn Unix.  It's not by studying
SVID, but rather by learning an implementation.  Often there's
"implicit knowledge" about Unix that is not clear from the POSIX
standard (although 1003.1 Draft 13 was much improved over Draft 12 in
that regard.  There's at least on instance in 1003.2 where I objected
to something in the draft for that very reason.)  Ada has had a
validation suite before there were any implementations; we as a
community have learned a lot about standards and measuring
conformance.  (I can provide a few war stories...)

So, my point is this:  I still believe Shane's characterization is
unfair.  What he sees as "lack of understanding" may very well be an
attempt to fully explore the rammifications of the P1003.1 standard,
as opposed to "common knowledge about Unix".

There are times when I think that the Unix community doesn't fully
understand their own semantics.  For instance, in the sample
Language Independent Definition, the type file_descriptor was made an
"opaque" type, one whose representation is not visible.  This won't
work.  In particular, if this type is not an integer, how do you
'name' file_descriptors that are not stdin, stdout and stderr?
Specifically, what is the 1003.1 meaning of 1003.2 I/O redirection for
FD 7, for instance?  As an active participant in many of these
discussions, I remember all the Unix arcana that wandered around the
1003.5 group trying to understand what the intended POSIX semantics
for file descriptors are.  We originally proposed that file_descriptor
be an Ada "private" type, but based on our knowledge of Unix, decided
that this would not work.

                dave emery
                [e-mail]

Volume-Number: Volume 16, Number 43

shar.89.05.1003.5.c.4632
echo 89.05.1003.5.d
cat >89.05.1003.5.d <<'shar.89.05.1003.5.d.4632'
From news  Wed Jun  7 17:16:11 1989
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: POSIX flame...
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: uunet!algor2!jeffrey (Jeffrey Kegler)
Organization: Algorists, Inc., Reston VA
Date: 7 Jun 89 17:31:04 GMT
Apparently-To: std-unix-archive

From: uunet!algor2!jeffrey (Jeffrey Kegler)

In article <[e-mail]> uunet!aries.mitre.org!emery
(David Emery) writes:

>We in the Ada community (regardless of Unix-literacy) have a heluva
>lot more experience with formal standards documents than the Unix
>community.

This is a bug not a feature.  The ADA community has done little so far
except work with standards.

>Consider how most people learn Unix.  It's not by studying
>SVID, but rather by learning an implementation.

Learning programming from a standard is like learning seamanship in the
Rockies.

Do not get me wrong.  While I earn my living from UNIX/C, I have studied
ADA, like many of its features, wish some were in UNIX, and would not
object to programming in ADA someday.  That day will never come if the ADA
community thinks it can do without input from UNIX practitioners.

Representation on the committee does not necessarily make any difference,
as long as there is input.  If this POSIX standard comes out as anything
less than a joint effort with the community of UNIX practitioners, the ADA
people will have done themselves a great disservice.  And I will have
wasted my time spent studying ADA.
--

Jeffrey Kegler, President, Algorists,
[e-mail] or uunet!algor2!jeffrey
1762 Wainwright DR, Reston VA 22090

[ Let's try to turn this back into a more technical discussion.  -mod ]

Volume-Number: Volume 16, Number 52

shar.89.05.1003.5.d.4632
echo 89.05.1003.6
cat >89.05.1003.6 <<'shar.89.05.1003.6.4632'
From root  Thu May 11 12:32:40 1989
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update Part 5: 1003.6
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 11 May 89 15:39:41 GMT
Apparently-To: std-unix-archive


Standards Update                              Part 5: 1003.6

          An update on UNIX|= Standards Activities
       January 1989 IEEE 1003 Meeting, Ft. Lauderdale

                      Part 5:  1003.6

           Shane P. McCarron, NAPS International

     1003.6 - Security Extensions to POSIX

     The security working group is currently working on a
number of topics in parallel - Autiding, Discretionary
Access Controls (DAC), Mandatory Access Controls (MAC), and
Privileges.  As these topics have been described in detail
in previous installments, I won't do it again.  Instead,
here is a brief summary of topics of interest being
discussed in those sub-committees:

     MACs

     The group decided to accept one proposal before them as
a baseline.  This will help them to decided on their exact
scope of operation and also to decide on their goals.  This
baseline proposal has not solved even a small percentage of
the problems facing this committee.  Things like information
label mechanisms, data transport, text label format, label
constraints, and security for public/shared directories were
too abstract at this time, the group decided to ask for
white papers to talk about them at the April meeting.

     AUDIT

     This group has embraced a proposal as a base.  This
proposal, in conjunction with a proposal from X/Open, will
probably be the primary source in this area.

     DAC

     This group was finally able to resolve some of the
issues that have been in dispute since its creation.  In
particular, the group was able to agree on:  The
representation of an Access Control List (ACL), Ordering,
Default ACLs, and most importantly the issue of how ACLs are
to be used in the system.  ACLs will be an additional
security mechanism, which much be enabled by explicit user

__________

  |= UNIX is a registered trademark of AT&T in the U.S. and
    other countries.

January 1989               - 1 -              Ft. Lauderdale


Standards Update                              Part 5: 1003.6

action.  This satisfies the requirements of the 1003.1
standard, which had left room for just such a mechanism by
leaving some weasel-wording in the definition of File Group
Class.  The specific mechanism will be that the permissions
available to users (or groups) listed in an ACL will be a
subset of those availabe using the traditional group
permissions of the file.

     In addition, the inheritance of ACLs was discussed.  It
appears as if the group will agree that the ACL for a
directory will propogate to any sub-directories that are
created.  However, this is still an issue and will be
debated at the April meeting.

     In addition, the group agreed that there will be
routines in the standard for manipulating each type of ACL,
and that named or shared ACLs will not be in the standard.

     PRIVILEGES:

     The principle of least privileges requires that each
subject in a system be granted the most restrictive set of
privileges needed for performance of authorized tasks.  The
principle of Least Privilege will also include the concept
that each privilege is available for the minimum scope of
execution required to perform the task for which it is
needed.

     The purpose of privileges is to assure the authorized
and restricted use of a service.  Security relevant code can
be bracketed and the privileges may be enabled only during
execution of that part of a program.

     Issues that need to be addressed by this group include:

  1.  To what degree can privileges be segmented to allow
      control over individual privileged actions?

  2.  How can a designer of a privilege propagation
      mechanism assure compliance with the principle of
      least privilege?

  3.  How can user access to privileged operations be
      limited in accordance with the principle of least
      privilege?

  4.  What control interfaces are necessary to allow
      privilege mechanism?

The group has agreed that no privilege should grant access
to more than a single set of related operations.  The group

January 1989               - 2 -              Ft. Lauderdale


Standards Update                              Part 5: 1003.6

also agreed that the propogation of a privilege from one
"subject" (process) to another should be strictly
controlled.  Because traditional implementations propogate
priviliege based on the effective user ID of a process, any
secure implementation will have to permit this behavior.
However, to permit for more secure software being developed
in the future, it is necessary to provide some primitives
that will permit a parent process to restrict which
privileges are progated to its children.

     The standard will be defining a set of interfaces for
accessing privileged operations.  These interfaces will
allow for: Reducing the level of privileges, setting,
creating, or adding privileges, acquiring privineges,
testing for privileges, requesting a privilege type, setting
privilege propogation, requesting a set of maximal
privileges, determining the set of privileges currently
enabled, determining the success or failure of privilege
accumulation, and creating of privileges not in the current
set.

     The scope of this committee is to define extensions to
the POSIX interface which support a privilege mechanism
capable of enforcing a 'Least Privilege' security policy,
and a minimum set of privileges which are necessary to
support such a policy in a portable applications
environment.

     The Usenix Standards Watchdog Committee contact for
this group is Anna Maria de Alvare.  She can be reached at:

          Anna Maria de Alvare
          Lawrence Livermore National Laboratories
          PO Box 808
          L-303
          Livermore, CA  94450
          [phone]
          [e-mail]
          uunet!lll-lcc.llnl.gov!annamaria

January 1989               - 3 -              Ft. Lauderdale


Volume-Number: Volume 16, Number 36

shar.89.05.1003.6.4632
echo 89.05.1003.7
cat >89.05.1003.7 <<'shar.89.05.1003.7.4632'
From root  Thu May 11 12:34:28 1989
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update Part 6: 1003.7
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 11 May 89 15:41:03 GMT
Apparently-To: std-unix-archive


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
          [phone]
          [e-mail]

January 1989               - 4 -              Ft. Lauderdale


Volume-Number: Volume 16, Number 37

shar.89.05.1003.7.4632
exit