home *** CD-ROM | disk | FTP | other *** search
Text File | 1990-08-02 | 174.9 KB | 4,114 lines |
- echo intro
- cat >intro <<'shar.intro.8174'
- From uucp@tic.com Sat Jun 30 00:05:58 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA18333; Sat, 30 Jun 90 00:05:58 -0400
- Posted-Date: 30 Jun 90 02:28:24 GMT
- Received: by cs.utexas.edu (5.64/1.65)
- id AA28562; Fri, 29 Jun 90 23:05:53 -0500
- Received: by longway.tic.com (4.22/tic.1.2)
- id AA12060; Fri, 29 Jun 90 23:12:47 cdt
- From: <jsh@usenix.org>
- Newsgroups: comp.std.unix
- Subject: Standards Update, USENIX Standards Watchdog Committee
- Message-Id: <386@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: std-unix@uunet.uu.net
- Date: 30 Jun 90 02:28:24 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
-
- An Update on UNIX*-Related Standards Activities
-
- June, 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer <jsh@ico.isc.com> reports on spring-quarter
- standards activities
-
- What these reports are about
-
- Reports are done quarterly, for the USENIX Association, by volunteers
- from the individual standards committees. The volunteers are
- familiarly known as snitches and the reports as snitch reports. The
- band of snitches and I make up the working committee of the USENIX
- Standards Watchdog Committee. Our job is to let you know about things
- going on in the standards arena that might affect your professional
- life -- either now or down the road a ways.
-
- We don't yet have active snitches for all the committees and sometimes
- have to beat the bushes for new snitches when old ones retire or can't
- make a meeting, but the number of groups with active snitches
- continues to grow (as, unfortunately, does the number of groups).
-
- We know we currently need snitches in 1003.6 (Security), 1003.11
- (Transaction Processing), 1003.13 (Real-time Profile), and nearly all
- of the 1200-series POSIX groups, There are probably X3 groups the
- USENIX members would like to know about that we don't even know to
- look for watchdogs in. If you're active in any other standards-
- related activity that you think you'd like to report on, please drop
- me a line. Andrew Hume's fine report on X3B11.1 is an example of the
- kind of submission I'd love to see.
-
- If you have comments or suggestions, or are interested in snitching
- for any group, please contact me (jsh@usenix.org) or John
- (jsq@usenix.org). If some of the reports make you interested enough
- or indignant enough to want to go to a POSIX meeting, or you just want
- to talk to me in person, join me at the next set, July 16-20, at the
- Sheraton Tara, in Danvers, Massachusetts, just outside of Boston.
-
- The USENIX Standards Watchdog Committee also has both a financial
- committee -- Ellie Young, Alan G. Nemeth, and Kirk McKusick (chair);
-
- __________
-
- * UNIX is a registered trademark of AT&T in the U.S. and other
- countries.
-
- June, 1990 Standards Update USENIX Standards Watchdog Committee
-
-
- - 2 -
-
- and a policy committee -- the financial committee plus John S.
- Quarterman (chair).
-
- An official statement from John:
-
- The basic USENIX policy regarding standards is:
- to attempt to prevent standards from prohibiting innovation.
- To do that, we
-
- + Collect and publish contextual and technical information
- such as the snitch reports that otherwise would be lost in
- committee minutes or rationale appendices or would not be
- written down at all.
-
- + Encourage appropriate people to get involved in the
- standards process.
-
- + Hold forums such as Birds of a Feather (BOF) meetings at
- conferences. We sponsored one workshop on standards. And
- are cosponsoring another in conjunction with IEEE, UniForum,
- and EUUG. (Co-chairs are Shane P. McCarron
- <ahby@uiunix.org> and Fritz Schulz <fritz@osf.osf.org>.
- Contact them for details.)
-
- + Write and present proposals to standards bodies in specific
- areas.
-
- + Occasionally sponsor White Papers in particularly
- problematical areas, such as IEEE 1003.7 (in 1989).
-
- + Very occasionally lobby organizations that oversee standards
- bodies regarding new committee, documents, or balloting
- procedures.
-
- + Starting in mid-1989, USENIX and EUUG (the European UNIX
- systems Users Group) began sponsoring a joint representative
- to the ISO/IEC JTC1 SC22 WG15 (ISO POSIX) standards
- committee.
-
- There are some things we do not do:
-
- + Form standards committees. It's the USENIX Standards
- Watchdog Committee, not the POSIX Watchdog Committee, not
- part of POSIX, and not limited to POSIX.
-
- + Promote standards.
-
- + Endorse standards.
-
- June, 1990 Standards Update USENIX Standards Watchdog Committee
-
-
- - 3 -
-
- Occasionally we may ask snitches to present proposals or argue
- positions on behalf of USENIX. They are not required to do so
- and cannot do so unless asked by the USENIX Standards Watchdog
- Policy Committee.
-
- Snitches mostly report. We also encourage them to recommend
- actions for USENIX to take.
-
- John S. Quarterman, USENIX Standards Liaison
-
- June, 1990 Standards Update USENIX Standards Watchdog Committee
-
- Volume-Number: Volume 20, Number 65
-
- shar.intro.8174
- echo overview
- cat >overview <<'shar.overview.8174'
- From uucp@tic.com Sat Jun 30 00:06:21 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA18462; Sat, 30 Jun 90 00:06:21 -0400
- Posted-Date: 30 Jun 90 02:42:08 GMT
- Received: by cs.utexas.edu (5.64/1.65)
- id AA28590; Fri, 29 Jun 90 23:06:04 -0500
- Received: by longway.tic.com (4.22/tic.1.2)
- id AA12117; Fri, 29 Jun 90 23:14:25 cdt
- From: <jsh@usenix.org>
- Newsgroups: comp.std.unix
- Subject: Standards Update, Recent Standards Activities
- Message-Id: <387@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: std-unix@uunet.uu.net
- Date: 30 Jun 90 02:42:08 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
-
- An Update on UNIX*-Related Standards Activities
-
- June, 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, jsh@ico.isc.com, Report Editor
-
- Recent Standards Activities
-
- This editorial is an overview of some of the spring-quarter standards
- activities covered by the USENIX Standards Watchdog Committee. A
- companion article provides a general overview of the committee itself.
-
- In this article, I've emphasized non-technical issues, which are
- unlikely to appear in official minutes and mailings of the standards
- committees. Previously published articles give more detailed, more
- technical views on most of these groups' activities. If my comments
- move you to read one of those earlier reports that you wouldn't have
- read otherwise, I've served my purpose. Of course, on reading that
- report you may discover the watchdog's opinion differs completely from
- mine.
-
- SEC: Standard/Sponsor Executive Committee
-
- The biggest hullabaloo in the POSIX world this quarter came out of the
- SEC, the group that approves creation of new committees. At the April
- meeting, in a move to slow the uncontrolled proliferation of POSIX
- standards, the institutional representatives (IRs) (one each from
- Usenix, UniForum, X/Open, OSF, and UI) recommended two changes in the
- Project Authorization Request (PAR) approval process: (1) firm
- criteria for PAR approval and group persistence and (2) a PAR-approval
- group that had no working-group chairs or co-chairs. Dale Harris, of
- IBM Austin, presented the proposal and immediately took a lot of heat
- from the attendees, most of whom are working-group chairs and co-
- chairs (Dale isn't an IR, but shared the concerns that motivated the
- recommendations and asked to make the presentation.)
-
- The chair, Jim Isaak, created an ad-hoc committee to talk over the
- proposal in a less emotional atmosphere. Consensus when the committee
- met was that the problem of proliferating PARs was real, and the only
- question was how to fix it. The group put together a formal set of
- criteria for PAR approval (which John Quarterman has posted to
- comp.std.unix), which seems to have satisfied everyone on the SEC, and
- passed without issue. The criteria seem to have teeth: at least one
- of the Project Authorization Requests presented later (1201.3, UIMS)
-
- __________
-
- * UNIX is a Registered Trademark of UNIX System Laboratories in the
- United States and other countries.
-
- June, 1990 Standards Update Recent Standards Activities
-
-
- - 2 -
-
- flunked the criteria and was rejected. Two others (1201.1 and 1201.4
- toolkits and Xlib) were deferred. I suspect (though doubt that any
- would admit it) that the proposals would have been submitted and
- passed in the absence of the criteria. In another related up-note,
- Tim Baker and Jim Isaak drafted a letter to one group (1224, X.400
- API), warning them that they must either prove they're working or
- dissolve.
-
- The second of the two suggestions, the creation of a PAR-approval
- subcommittee, sank quietly. The issue will stay submerged so long as
- it looks like the SEC is actually using the approved criteria to fix
- the problem. [ Actually, this may not be true. Watch for developments
- at the next meeting, in Danvers, MA in mid-July. -jsq]
-
- Shane McCarron's column in the July Unix Review covers this area in
- more detail.
-
- 1003.0: POSIX Guide
-
- Those of you who have read my last two columns will know that I've
- taken the position that dot zero is valuable, even if it doesn't get a
- lot of measurable work done. This time, I have to say it looks like
- it's also making measurable progress, and may go to mock ballot by its
- target of fourth quarter of this year. To me, the most interesting
- dot-zero-related items this quarter are the growing prominence of
- profiles, and the mention of dot zero's work in the PAR-approval-
- criteria passed by the SEC.
-
- Al Hankinson, the chair, tells me that he thinks dot zero's biggest
- contribution has been popularizing profiles -- basically,
- application-area-specific lists of pointers to other standards. This
- organizing principle has been adopted not only by the SEC (several of
- the POSIX groups are writing profiles), but by NIST (Al's from NIST)
- and ISO. I suspect a lot of other important organizations will fall
- in line here.
-
- Nestled among the other criteria for PAR approval, is a requirement
- that PAR proposers write a sample description of their group for the
- POSIX guide. Someone questioned why proposers should have to do dot
- zero's job for them. The explanation comes in two pieces. First, dot
- zero doesn't have the resources to be an expert on everything, it has
- its hands full just trying to create an overall architecture. Second,
- the proposers aren't supplying what will ultimately go into the POSIX
- guide, they're supplying a sample. The act of drafting that sample
- will force each proposer to think hard about where the new group would
- fit in the grand scheme, right from the start. This should help
- insure that the guide's architecture really does reflect the rest of
- the POSIX effort, and will increase the interest of the other groups
- in the details of the guide.
-
- June, 1990 Standards Update Recent Standards Activities
-
-
- - 3 -
-
- 1003.1: System services interface
-
- Dot one, the only group that has completed a standard, is in the
- throes of completing a second. Not only has the IEEE updated the
- existing standard -- the new version will be IEEE 1003.1-1990 -- ISO
- appears on the verge of approving the new version as IS 9945-1. The
- major sticking points currently seem limited to things like format and
- layout -- important in the bureaucratic world of international
- standards, but inconsequential to the average user. Speaking of
- layout, one wonders whether the new edition and ISO versions will
- retain the yellow-green cover that has given the current document its
- common name -- the ugly green book. (I've thought about soaking mine
- in Aqua Velva so it can smell like Green Chartreuse, too.)
-
- The interesting issues in the group are raised by the dot-one-b work,
- which adds new functionality. (Read Paul Rabin's snitch report for
- the gory details.) The thorniest problem is the messaging work.
- Messaging, here, means a mechanism for access to external text and is
- unrelated to msgget(), msgop(), msgctl(), or any other message-passing
- schemes. The problem being addressed is how to move all printable
- strings out of our programs and into external ``message'' files so
- that we can change program output from, say, English to German by
- changing an environmental variable. Other dot-one-b topics, like
- symbolic links, are interesting, but less pervasive. This one will
- change the way you write any commercial product that outputs text --
- anything that has printf() statements.
-
- The group is in a quandary. X/Open has a scheme that has gotten a
- little use. We're not talking three or four years of shake-out, here,
- but enough use to lay a claim to the ``existing practice'' label. On
- the other hand, it isn't a very pleasant scheme, and you'd have no
- problem coming up with candidate alternatives. The UniForum
- Internationalization Technical Committee presented one at the April
- meeting. It's rumored that X/Open itself may replace its current
- scheme with another. So, what to do? Changing to a new scheme
- ignores existing internationalized applications and codifies an
- untried approach. Blessing the current X/Open scheme freezes
- evolution at this early stage and kills any motivation to develop an
- easy-to-use alternative. Not providing any standard makes
- internationalized applications (in a couple of years this will mean
- any non-throw-away program) non-portable, and requires that we
- continue to have to make heavy source-code modifications on every
- port -- just what POSIX is supposed to help us get around.
-
- To help you think about the problem, here's the way you'll have to
- write the "hello, world" koan using the X/OPEN interfaces:
-
- June, 1990 Standards Update Recent Standards Activities
-
-
- - 4 -
-
- #include <stdio.h>
- #include <nl_types.h>
- #include <locale.h>
- main()
- {
- nl_catd catd;
-
- (void)setlocale(LC_ALL, "");
- catd = catopen("hello", 0); /* error checking omitted for brevity */
- printf(catgets(catd, 1, 1,"hello, world\n"));
- }
-
- and using the alternative, proposed UniForum interfaces:
-
- #include <stdio.h>
- #include <locale.h>
- main()
- {
- (void)setlocale(LC_ALL, "");
- (void)textdomain("hello");
- printf(gettext("hello, world\n"));
- }
-
- I suppose if I had my druthers, I'd like to see a standard interface
- that goes even farther than the UniForum proposal: one that adds a
- default message catalogue/group (perhaps based on the name of the
- program) and a standard, printf-family messaging function to hide the
- explicit gettext() call, so the program could look like this:
-
- #include <stdio.h>
- #include <locale.h>
- #define printf printmsg
- main()
- {
- (void)setlocale(LC_ALL, ""); /* inescapable, required by ANSI C */
- printf("hello, world\n");
- }
-
- but that would still be untested innovation.
-
- The weather conditions in Colorado have made this a bonus year for
- moths. Every morning, our bathroom has about forty moths in it.
- Stuck in our house, wanting desperately to get out, they fly toward
- the only light that they can see and beat themselves to death on the
- bathroom window. I don't know what to tell them, either.
-
- June, 1990 Standards Update Recent Standards Activities
-
-
- - 5 -
-
- 1003.2: Shell and utilities
-
- Someone surprised me at the April meeting by asserting that 1003.2
- might be an important next target for the FORTRAN binding group.
- (``What does that mean?'' I asked stupidly. ``A standard for a
- FORTRAN-shell?'') Perhaps you, like I, just think of dot two as
- language-independent utilities. Yes and no.
-
- First, 1003.2 has over a dozen function calls (e.g., getopt()). I
- believe that most of these should be moved into 1003.1. System() and
- popen(), which assume a shell, might be exceptions, but having
- sections of standards documents point at things outside their scope is
- not without precedent. Section 8 of P1003.1-1988 is a section of C-
- language extensions, and P1003.5 will depend on the Ada standard. Why
- shouldn't an optional section of dot one depend on dot two? Perhaps
- ISO, already committed to re-grouping and re-numbering the standards,
- will fix this. Perhaps not. In the meantime, there are functions in
- dot two that need FORTRAN and Ada bindings.
-
- Second, the current dot two standard specifies a C compiler. Dot nine
- has already helped dot two name the FORTRAN compiler, and may want to
- help dot two add a FORTRAN equivalent of lint (which I've heard called
- ``flint''). Dot five may want to provide analogous sorts of help
- (though Ada compilers probably already subsume much of lint's
- functionality).
-
- Third, more subtle issues arise in providing a portable utilities
- environment for programmers in other languages. Numerical libraries,
- like IMSL, are often kept as single, large source files with hundreds,
- or even thousands, of routines in a single .f file that compiles into
- a single .o file. Traditional FORTRAN environments provide tools that
- allow updating or extraction of single subroutines or functions from
- such objects, analogous to the way ar can add or replace single
- objects in libraries. Dot nine may want to provide such a facility in
- a FORTRAN binding to dot two.
-
- Anyway, back to the working group. They're preparing to go to ballot
- on the UPE (1003.2a, User Portability Extensions). The mock ballot
- had pretty minimal return, with only ten balloters providing
- approximately 500 objections. Ten isn't very many, but mock ballot
- for dot two classic only had twenty-three. It seems that people won't
- vote until they're forced to.
-
- The collection of utilities in 1003.2a is fairly reasonable, with only
- a few diversions from historic practice. A big exception is ps(1),
- where historic practice is so heterogeneous that a complete redesign
- is possible. Unfortunately, no strong logical thread links the
- 1003.2a commands together, so read the ballot with an eye toward
- commands that should be added or discarded.
-
- June, 1990 Standards Update Recent Standards Activities
-
-
- - 6 -
-
- A few utilities have already disappeared since the last draft. Pshar,
- an implementation of shar with a lot of bells and whistles, is gone.
-
- Compress/uncompress poses an interesting problem. Though the utility
- is based on clear-cut existing practice, the existing implementation
- uses an algorithm that is copyrighted. Unless the author chooses to
- give the algorithm away (as Ritchie dedicated his set-uid patent to
- public use), the committee is faced with a hard choice:
-
- - They can specify only the user interface. But the purpose of
- these utilities is to ease the cost of file interchange. What
- good are they without a standard data-interchange format?
-
- - They can invent a new algorithm. Does it make sense to use
- something that isn't field-tested or consistent with the versions
- already out there? (One assumes that the existing version has
- real advantages, otherwise, why would so many people use a
- copyrighted version?)
-
- Expect both the first real ballot of 1003.2a and recirculation of
- 1003.2 around July. Note that the recirculation will only let you
- object to items changed since the last draft, for all the usual bad
- reasons.
-
- 1003.3: Test methods
-
- The first part of dot three's work is coming to real closure. The
- last ballot failed, but my guess is that one will pass soon, perhaps
- as soon as the end of the year, and we will have a standard for
- testing conformance to IEEE 1003.1-1988.
-
- That isn't to say that all is rosy in dot-one testing. NIST's POSIX
- Conformance Test Suite (PCTS) still has plenty of problems:
- misinterpretations of dot one, simple timing test problems that cause
- tests to run well on 3b2's, but produce bad results on a 30 mips
- machine and even real bugs (attempts to read from a tty without first
- opening it). POSIX dot one is far more complex than anything for
- which standard test suites have been developed to date. The PCTS,
- with around 2600 tests and 150,000 lines of code, just reflects that
- complexity. An update will be sent to the National Technical
- Information Service (NTIS -- also part of the Department Commerce, but
- not to be confused with NIST) around the end of September which fixes
- all known problems but, with a suite this large, others are likely to
- surface later.
-
- By the way, NIST's dot one suite is a driver based on the System V
- Verification Suite (SVVS), plus individual tests developed at NIST.
- Work has begun on a suite of tests for 1003.2, based, for convenience,
- on a suite done originally for IBM by Mindcraft. It isn't clear how
- quickly this work will go. (For example, the suite can't gel until
- dot two does.) For the dot one work, NIST made good use of Research
-
- June, 1990 Standards Update Recent Standards Activities
-
-
- - 7 -
-
- Associates -- people whose services were donated by their corporations
- during the test suite development. Corporations gain an opportunity
- to collaborate with NIST and inside knowledge of the test suite. I
- suspect Roger Martin may now be seeking Research Associates for dot
- two test suite development. If you're interested in doing this kind
- of work, want to spend some time working in the Washington, D.C. area,
- and think your company would sponsor you, his email address is
- rmartin@swe.ncsl.nist.gov.
-
- By the way, there are a variety of organizational and numbering
- changes happening in dot three. See Doris Lebovits's snitch report
- for details.
-
- The Steering Committee on Conformance Testing (SCCT) is the group to
- watch. Though they've evolved out of the dot three effort, they
- operate at the TCOS level, and are about to change the way POSIX
- standards look. In response to the ever-increasing burden placed on
- the testing committee, the SCCT is going to recommend that groups
- producing new standards include in those standards a list of test
- assertions to be used in testing them.
-
- Groups that are almost done, like 1003.2, will be grandfathered in.
- But what should be done with a group like dot four -- not far enough
- along that it has something likely to pass soon, but far enough to
- make the addition of major components to its ballot a real problem.
- Should this case be treated like language independence? If so,
- perhaps dot four will also be first in providing test assertions.
-
- 1003.4: Real-time extensions
-
- The base dot-four document has gone to ballot, and the ensuing process
- looks like it may be pretty bloody. Fifty-seven percent of the group
- voted against the current version. (One member speculated privately
- that this meant forty-three percent of the balloting group didn't read
- it.) Twenty-two percent of the group (nearly half of those voting
- against) subscribed to all or part of a common reference ballot, which
- would require that entire chapters of the document be completely
- reworked, replaced, or discarded. Subscribers to this common
- reference ballot included employees of Unix International and the Open
- Software Foundation, of Carnegie-Mellon University and the University
- of California at Berkeley, and of Sun Microsystems and Hewlett-
- Packard. (USENIX did not ballot similarly, but only because of lack
- of time.) Some of these organizations have never before agreed on the
- day of the week, let alone the semantics of system calls. But then,
- isn't bringing the industry together one goal of POSIX?
-
- Still, the document has not been returned to the working group by the
- technical editors, so we can assume they feel hopeful about resolving
- all the objections. Some of this hope may come from the miracle of
- formality. I've heard that over half of the common reference ballot
- could be declared non-responsive, which means that there's no
-
- June, 1990 Standards Update Recent Standards Activities
-
-
- - 8 -
-
- obligation to address over half the concerns.
-
- The threads work appears to enjoy a more positive consensus. At least
- two interesting alternatives to the current proposal surfaced at the
- April meeting, but following a lot of discussion, the existing
- proposal stood largely unchanged. I predict that the threads work
- which will go to ballot after the base, dot four document, will be
- approved before it. John Gertwagen, dot four snitch and chair of
- UniForum's real-time technical committee, has bet me a beer that I'm
- wrong.
-
- 1003.5: Ada bindings and 1003.9: FORTRAN-77 bindings
-
- These groups are coming to the same place at the same time. Both are
- going to ballot and seem likely to pass quickly. In each case, the
- major focus is shifting from technical issues to the standards process
- and its rules: forming balloting groups, relations with ISO, future
- directions, and so on.
-
- Here's your chance to do a good deed without much work. Stop reading,
- call someone you know who would be interested in these standards, and
- give them the name of someone on the committee who can put them into
- the balloting group. (If nothing else, point them at our snitches for
- this quarter: Jayne Baker cgb@d74sun.mitre.org, for dot five, and
- Michael Hannah mjhanna@sandia.gov, for dot nine.) They'll get both a
- chance to see the standard that's about to land on top of their work
- and a chance to object to anything that's slipped into the standard
- that doesn't make sense. The more the merrier on this one, and they
- don't have to go to any committee meetings. I've already called a
- couple of friends of mine at FORTRAN-oriented companies; both were
- pleased to hear about 1003.9, and eager to read and comment on the
- proposed standard.
-
- Next up for both groups, after these standards pass, is negotiating
- the IEEE standard through the shoals of ISO, both getting and staying
- in sync with the various versions and updates of the base standard
- (1003.1a, 1003.1b, and 9945-1), and language bindings to other
- standards, like 1003.2 and 1003.4. (See my earlier discussion of dot
- two.) Notice that they also have the burden of tracking their own
- language standards. At least in the case of 1003.9, this probably
- means eventually having to think about a binding to X3J3 (Fortran 90).
-
- 1003.6: Security
-
- This group has filled the long-vacant post of technical editor, and,
- so, is finally back in the standards business. In any organization
- whose ultimate product is to be a document, the technical editor is a
- key person. [We pause here to allow readers to make some obligatory
- cheap shot about editors.] This is certainly the case in the POSIX
- groups, where the technical editors sometimes actually write large
- fractions of the final document, albeit under the direction of the
-
- June, 1990 Standards Update Recent Standards Activities
-
-
- - 9 -
-
- working group.
-
- I'm about to post the dot six snitch report, and don't want to give
- any of it away, but will note that it's strongly opinionated and
- challenges readers to find any non-DoD use for Mandatory Access
- Control, one of the half-dozen areas that they're standardizing.
-
- 1003.7: System administration
-
- This group has to solve two problems at different levels at the same
- time. On the one hand, it's creating an object-oriented definition of
- system administration. This high-level approach encapsulates the
- detailed implementation of objects interesting to the system
- administrator (user, file system, etc.), so that everyone can see them
- in the same way on a heterogeneous environment. On the other hand,
- the protocol for sending messages to these objects must be specified
- in detail. If it isn't, manufacturers won't be able to create
- interoperable systems.
-
- The group as a whole continues to get complaints about its doing
- research-by-committee. It's not even pretending to standardize
- existing practice. I have mixed feelings about this, but am
- unreservedly nervous that some of the solutions being contemplated
- aren't even UNIX-like. For example, the group has tentatively
- proposed the unusual syntax object action. Command names will be
- names of objects, and the things to be done to them will be arguments.
- This bothers me (and others) for two reasons. First, this confuses
- syntax with semantics. You can have the message name first and still
- be object-oriented; look at C++. Second, it reverses the traditional,
- UNIX verb-noun arrangement: mount filesystem becomes filesystem mount.
- This flies in the face of the few existing practices everyone agrees
- on. I worry that these problems, and the resulting inconsistencies
- between system administration commands and other utilities, will
- confuse users. I have a recurring nightmare of a long line of new
- employees outside my door, all come to complain that I've forgotten to
- mark one of my device objects, /dev/null, executable.
-
- With no existing practice to provide a reality-check, the group faces
- an uphill struggle. If you're an object-oriented maven with a yen to
- do something useful, take a look at what this group is doing, then
- implement some of it and see if it makes sense. Look at it this way:
- by the time the standard becomes reality, you'll have a product, ready
- to ship.
-
- 1003.10: Supercomputing
-
- This group is working on things many of us us old-timers thought we
- had seen the last of: batch processing and checkpointing. The
- supercomputing community, condemned forever to live on the edge of
- what computers can accomplish, is forced into the same approaches we
- used back when computer cycles were harder to come by than programmer
- cycles, and machines were less reliable than software.
-
- June, 1990 Standards Update Recent Standards Activities
-
-
- - 10 -
-
- Supercomputers run programs that can't be run on less powerful
- computers because of their massive resource requirements
- (cpu/memory/io). They need batch processing and checkpointing because
- many of them are so resource-intensive that they even run for a long
- time on supercomputers. Nevertheless, the supercomputing community is
- not the only group that would benefit from standardization in these
- areas. (See, for example, my comments on dot fourteen.) Even people
- who have (or wish to have) long-running jobs on workstations, share
- some of the same needs for batch processing and checkpointing.
-
- Karen Sheaffer, the chair of dot ten, had no trouble quickly recasting
- the group's proposal for a batch PAR into a proposal that passed the
- SEC's PAR-approval criteria. The group is modeling a batch proposal
- after existing practice, and things seem to be going smoothly.
-
- Checkpointing, on the other hand, isn't faring as well. People who
- program supercomputers need to have a way to snapshot jobs in a way
- that lets them restart the jobs at that point later. Think, for
- example, of a job that needs to run for longer than a machine's mean-
- time-to-failure. Or a job that runs for just a little longer than
- your grant money lasts. There are existing, proprietary schemes in
- the supercomputing world, but none that's portable. The consensus is
- that a portable mechanism would be useful and that support for
- checkpointing should be added to the dot one standard. The group
- brought a proposal to dot one b, but it was rejected for reasons
- detailed in Paul Rabin's dot one report. Indeed, the last I heard,
- dot-one folks were suggesting that dot ten propose interfaces that
- would be called from within the program to be checkpointed. While
- this may seem to the dot-one folks like the most practical approach,
- it seems to me to be searching under the lamp-post for your keys
- because that's where the light's brightest. Users need to be able to
- point to a job that's run longer than anticipated and say,
- ``Checkpoint this, please.'' Requiring source-code modification to
- accomplish this is not only unrealistic, it's un-UNIX-like. (A
- helpful person looking over my shoulder has just pointed out that the
- lawyers have declared ``UNIX'' an adjective, and I should say
- something like ``un-UNIX-system-like'' instead. He is, of course,
- correct.) Whatever the interface is, it simply must provide a way to
- let a user point at another process and say, ``Snapshot it,'' just as
- we can stop a running job with job control.
-
- 1003.12: Protocol-independent interfaces
-
- This group is still working on two separate interfaces to the network:
- Simple Network Interface (SNI) and Detailed Network Interface (DNI).
- The January meeting raised the possibility that the group would
- coalesce these into a single scheme, but that scheme seems not to have
- materialized. DNI will provide a familiar socket- or XTI/TLI-like
- interface to networks, while SNI will provide a simpler, stdio-like
-
- June, 1990 Standards Update Recent Standards Activities
-
-
- - 11 -
-
- interface for programs that don't need the level of control that DNI
- will provide. The challenge of SNI is to make something that's simple
- but not so crippled that it's useless. The challenge of DNI is to
- negotiate the fine line between the two competing, existing practices.
- The group has already decided not to use either sockets or XTI, and is
- looking at requirements for the replacement. Our snitch, Andy
- Nicholson, challenged readers to find a reason not to make DNI
- endpoints POSIX file descriptors, but has seen no takers.
-
- 1003.14: Multiprocessing
-
- The multiprocessing group, which had been meeting as sort of an ad-hoc
- spin-off of the real-time group, was given PAR approval at the April
- meeting as 1003.16 but quickly renamed 1003.14 for administrative
- reasons. They're currently going through the standard set of jobs
- that new groups have to accomplish, including figuring out what tasks
- need to be accomplished, whom to delegate them to, and how to attract
- enough working-group members to get everything done. If you want to
- get in on the ground floor of the multiprocessing standard, come to
- Danvers and volunteer to do something.
-
- One thing that needs to be done is liaison work with other committees,
- many of which are attacking problems that bear on multiprocessors as
- well. One example is dot ten's checkpointing work, which I talked
- about earlier, Checkpointing is both of direct interest to dot
- fourteen, and is analogous to several other problems the group would
- like to address. (A side-effect of the PAR proliferation problem
- mentioned earlier is that inter-group coordination efforts go up as
- the square of the number of groups.)
-
- 1201: Windows, sort of
-
- Okay, as a review, we went into the Utah meeting with one official
- group, 1201, and four unofficial groups preparing PARs:
-
- 1. 1201.1: Application toolkit
-
- 2. 1201.2: Recommended Practice for Driveability/User Portability
-
- 3. 1201.3: User Interface Management Systems
-
- 4. 1201.4: Xlib
-
- By the end of the week, one PAR had been shot down (1201.3), one
- approved (1201.2), and two remained unsubmitted.
-
- The 1201.4 par was deferred because the X consortium says Xlib is
- about to change enough that we don't want to standardize the existing
- version. I'll ask, ``If it's still changing this fast, do we want to
- even standardize on the next version?'' The 1201.1 PAR was deferred
- because the group hasn't agreed on what it wants to do. At the
-
- June, 1990 Standards Update Recent Standards Activities
-
-
- - 12 -
-
- beginning of the week, the two major camps (OSF/Motif and OPEN LOOK)*
- had agreed to try to merge the two interfaces. By mid-week, they
- wouldn't even sit at the same table. That they'd struck off in an
- alternative, compromise direction by the end of the week speaks
- extremely highly of all involved. What the group's looking at now is
- a toolkit at the level of XVT**: a layer over all of the current,
- competing technologies that would provide portability without
- invalidating any existing applications. This seems like just the
- right approach. (I have to say this because I suggested it in an
- editorial about six months ago.)
-
- The 1201.3 PAR was rejected. Actually, 1201 as a whole voted not to
- submit it, but the people working on it felt strongly enough that they
- submitted it anyway. The SEC's consensus was that the field wasn't
- mature enough to warrant even a recommended practice, but the work
- should continue, perhaps as a UniForum Technical Committee. The study
- group countered that it was important to set a standard before there
- were competing technologies, and that none of the attendees sponsoring
- companies would be willing to foot the bill for their work within
- anything but a standards body. The arguments weren't persuasive.
-
- The 1201.2 PAR, in contrast, sailed through. What's interesting about
- this work is that it won't be an API standard. A fair fraction of the
- committee members are human-factors people, and the person presenting
- the PAR convinced the SEC that there is now enough consensus in this
- area that a standard is appropriate. I'm willing to believe this, but
- I think that stretching the net of the IEEE's Technical Committee on
- Operating Systems so wide that it takes in a human-factors standard
- for windowing systems is overreaching.
-
- X3
-
- There are other ANSI-accredited standards-sponsoring bodies in the
- U.S. besides the IEEE. The best known in our field is the Computer
- Business Equipment Manufacturers' Association (CBEMA), which sponsors
- the X3 efforts, recently including X3J11, the ANSI-C standards
- committee. X3J11's job has wound down; Doug Gwyn tells me that
- there's so little happening of general interest that it isn't worth a
- report. Still, there's plenty going on in the X3 world. One example
- is X3B11, which is developing a standard for file systems on optical
- disks. Though this seems specialized, Andrew Hume suggests in his
-
- __________
-
- * OSF/Motif is a Registered Trademark of the Open Software
- Foundation.
- OPEN LOOK is a Registered Trademark of AT&T.
-
- ** XVT is a trademark of XVT Software Inc.
-
- June, 1990 Standards Update Recent Standards Activities
-
-
- - 13 -
-
- report that this work may eventually evolve into a standards effort
- for file systems on any read-write mass storage device. See the dot-
- four common reference ballot for the kind of feelings new file-system
- standards bring out.
-
- I encourage anyone out there on an X3 committee who thinks the
- committee could use more user exposure and input to file a report.
- For example, Doug Gwyn suggests that there is enough activity in the
- C++ standards world to merit a look. If anyone out there wants to
- volunteer a report, I'd love to see it.
-
- June, 1990 Standards Update Recent Standards Activities
-
- Volume-Number: Volume 20, Number 66
-
- From jsq@tic.com Thu Jul 5 20:32:28 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA13819; Thu, 5 Jul 90 20:32:28 -0400
- Posted-Date: 5 Jul 90 21:24:17 GMT
- Received: by cs.utexas.edu (5.64/1.68)
- id AA19756; Thu, 5 Jul 90 19:32:24 -0500
- Received: by longway.tic.com (4.22/tic.1.2)
- id AA05492; Thu, 5 Jul 90 19:18:46 cdt
- From: Jeffrey S. Haemer <jsh@usenix.org>
- Newsgroups: comp.std.unix
- Subject: correction (compression algorithm patents)
- Message-Id: <787@longway.TIC.COM>
- References: <387@usenix.ORG>
- Sender: std-unix@tic.com
- Reply-To: std-unix@uunet.uu.net
- Date: 5 Jul 90 21:24:17 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: jsh@usenix.org (Jeffrey S. Haemer)
-
- Five people have now brought to my attention that my
- recent editorial says the compress/uncompress algorithm is
- copyrighted: Dave Grindelman, Guy Harris, Keith Bostic, Randall
- Howard, and Hugh Redelmeier. That's wrong. It isn't
- copyrighted, it's patented. My apologies to anyone I mislead.
-
- Randall's note contains a lot of interesting details that it's worth posting
- and he's given me permission to post it.
- I've appended it.
-
- Jeff
-
- =====
- [From Randall Howard]
-
- Actually the problem is not that the compress algorithm is copyrighted
- but that it is PATENTED by Welch (the "W" in the LZW name of the algorithm).
- The patent is currently held by Unisys Corporation and they make money
- from licence fees on that patent because of the use of LZW encoding
- in the new high-speed modems. Note that the Lempel-Ziv algorithm
- is apparently not patented, but just the Welch variant as is found in the
- UNIX compress utility. Therefore, at the cost of inventing a new file
- compression standard, it would be possible to escape licence fees by
- using a different variant of LZ compression.
-
- [Editor: Keith Bostic says both are patented:
- original Ziv-Lempel is patent number 4,464,650,
- and the more powerful LZW method is #4,558,302.
- He goes on to say, however, that LZW lacks adaptive table reset
- and other features in compress, and so may not apply.]
-
- The implications of this are that no one may produce the same
- output as compress produces, regardless of the program that produced
- that output, without being subject to the patent. I.e., it is independent
- of the actually coding used, unlike copyright. Therefore, all of the PD
- versions of compress are currently in violation, as is BSD.
-
- Representatives of Unisys at the POSIX.2 meetings claimed that
- the Unisys Legal Department is pursuing the licensing of compress. In fact,
- unlike copyright or trade secret protection, patent protection does not
- diminish because the holder of the patent is not diligent in seeking damages
- or preventing unauthorized use. Witness the large royalty payout by
- Japanese semiconductor companies to Texas Instruments because they held
- the patent on the concept of something as fundamental as integrated circuits.
- This licence payout spans a period of over 20 years. In addition,
- Unisys representatives claim that Phil Karn's PKZIP, which uses the
- LZW compression algorithm, is a licenced user of the Unisys patent and
- that a fee (rumoured to be somewhere in the $10,000 to $20,000 US range)
- has been paid up front in lieu of individual royalties.
-
- The ramifications for POSIX.2a are unclear. Currently, there are members
- of the working group that say that they would object if a patented
- algorithm were required by the standard if ANY FEE WHATSOEVER (even if $1)
- were required to use it. (There are, however, precedents for standards
- working in areas of patents in such areas as networking, modems, and
- hardware bus structures. It appears that we software people have not
- "grown up" as much when it comes to issues of licensing. Who has ever
- hear of "public domain hardware"?) Some people suggested that Unisys
- should allow relatively free use of the patent but should profit from
- publicity rights from a citation in every POSIX.2a product manual that
- contains compress. Therefore, there are currently negotiations underway
- to see what kind of "special deal" Unisys would be willing to cut for the
- use strictly in implementations of POSIX.2a. Depending on the outcome
- of these negotiations, compress would either be dropped, re-engineered,
- or retained.
-
- Volume-Number: Volume 20, Number 101
-
- shar.overview.8174
- echo 1003.0
- cat >1003.0 <<'shar.1003.0.8174'
- From jsq@longway.tic.com Sat May 19 15:44:08 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA28102; Sat, 19 May 90 15:44:08 -0400
- Posted-Date: 19 May 90 19:18:00 GMT
- Received: by cs.utexas.edu (5.61/1.62)
- id AA06935; Sat, 19 May 90 14:44:04 -0500
- Received: by longway.tic.com (4.22/4.16)
- id AA10960; Sat, 19 May 90 14:19:07 cdt
- From: <usenix.org!jsh@longway.tic.com>
- Newsgroups: comp.std.unix
- Subject: Standards Update, IEEE 1003.0: POSIX Guide
- Message-Id: <693@longway.TIC.COM>
- Sender: std-unix@longway.tic.com
- Reply-To: std-unix@uunet.uu.net
- Date: 19 May 90 19:18:00 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
-
- An Update on UNIX*-Related Standards Activities
-
- May 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- IEEE 1003.0: POSIX Guide
-
- Kevin Lewis <klewis@gucci.dco.dec.com> reports on the April 23-27
- meeting in Salt Lake City, UT:
-
- Where we are
-
- The Utah meeting of the IEEE 1003.0 working group marks the beginning
- of its third year. Let's step back for a moment to review the past
- two. We have gone from scratch to a 180-page document, whose content
- represents about 70% of the content goal that we set for our work two
- years ago. (More on this in a moment.)
-
- This effort represents the contributions of a core group of 15 to 18
- people. In 1988, 14 vendor organizations and 16 user organizations
- were represented within the group. Today, we have nine vendor
- organizations and 16 user organizations represented. Of course, the
- only official, formal organizational representatives allowed within
- IEEE working groups are accredited, institutional representatives
- (currently Usenix, UniForum, X/Open, Unix International, and the Open
- Software Foundation each supply one to the POSIX effort), but that
- does not stop me from checking the sign-up sheet whenever a new face
- shows up, to see where he or she works. For example, I think someone
- from the Univ. of Berkeley involved in BSD UNIX development has a
- vendor's perspective, while I place attendees from NIST and the Air
- Force in the user category because I believe they focus on the
- interests of their own end users. Our stable, steady user
- representation is essential: our ultimate targets are users trying to
- walk through the POSIX maze.
-
- The 70% completion of our initial content goal includes the
- introduction of the ``profile'' concept, which has led to increased
- activity within the IEEE TCOS Standards Subcommittee to create groups
- to define profiles (which may be good or bad depending on your own
- prism). The concept of profiles is also part of the US's contribution
- to the ISO community, made through its participation in the JTC1
- Technical Study Group on Application Portability (JTAP), within which
- the ``profiles'' concept has now garnered wide acceptance.
-
- __________
-
- * UNIX is a registered trademark of AT&T in the U.S. and other
- countries.
-
- May 1990 Standards Update IEEE 1003.0: POSIX Guide
-
-
- - 2 -
-
- ``What is a profile?'' you ask. Users seeking open system solutions
- need to know what parts of the open system environment (OSE) address
- their requirements. If a user could reach into the full basket of OSE
- parts and pull out only those he specifically needs, those selected
- parts would be his application environment profile. What he should do
- if he needs something not in the basket? Come to our next meeting
- with a recommendation. [Editor: Or drop Kevin a line, or post
- something to comp.std.unix!]
-
- Where we're going
-
- Dot Zero still faces hard decisions in two areas:
-
- 1. the necessity or desirability of parts of our guide. (Two parts
- that I very much think are candidates for this discussion are
- User Interface and Security)
-
- 2. The final bounds of the profile concept/definition.
-
- The group's arguments in these areas are not frivolous, but if they
- continue much longer, the resulting lack of movement will hurt our
- overall effort.
-
- I came out of this meeting feeling that everyone is committed to
- getting over these hurdles soon (i.e., by the July meeting). Our
- chair, Al Hankinson, has also stated that we should target December,
- 1990 for a mock ballot. I wholeheartedly agree. This will add the
- impetus that we need. Let's see if we have the self-discipline to get
- there.
-
- May 1990 Standards Update IEEE 1003.0: POSIX Guide
-
- Volume-Number: Volume 20, Number 3
-
- shar.1003.0.8174
- echo 1003.1
- cat >1003.1 <<'shar.1003.1.8174'
- From uucp@tic.com Thu Jun 28 18:15:17 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA24519; Thu, 28 Jun 90 18:15:17 -0400
- Posted-Date: 28 Jun 90 18:34:23 GMT
- Received: by cs.utexas.edu (5.64/1.65)
- id AA25755; Thu, 28 Jun 90 17:15:02 -0500
- Received: by longway.tic.com (4.22/tic.1.2)
- id AA06579; Thu, 28 Jun 90 16:10:59 cdt
- From: <jsh@usenix.org>
- Newsgroups: comp.std.unix
- Subject: Standards Update, IEEE 1003.1: System services interface
- Message-Id: <385@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: std-unix@uunet.uu.net
- Date: 28 Jun 90 18:34:23 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
- An Update on UNIX*-Related Standards Activities
-
- June, 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- IEEE 1003.1: System services interface
-
- Paul Rabin <rabin@osf.org> reports on the April 23-27 meeting in Salt
- Lake City, UT:
-
- 1. Introduction
-
- The POSIX 1003.1 working group is the oldest POSIX group, responsible
- for specifying general-purpose operating system interfaces for
- portable applications. This group developed the original 1988 POSIX
- standard, and is now responsible for writing supplements and revisions
- to that standard. This work includes
-
- + corrections and clarifications to the 1988 POSIX standard
-
- + material that was too controversial to handle before
-
- + new interfaces requested by other POSIX working groups
-
- Like other working groups developing ``base standards,'' the 1003.1
- working group is responsible for writing both C language and
- language-independent versions of the specifications that it develops.
- So far, the group has concentrated on the C language versions, but
- there is increasing pressure to make progress on the language-
- independent specifications.
-
- The working group recently completed a revision of the 1988 POSIX
- standard, and is currently working on a supplement to that revision.
-
- There has been a lot of turnover in the group since the 1988 POSIX
- standard was completed, but there are still a few old-timers to
- provide continuity. About 15 people attended the last two meetings.
- This seems to be a good size for getting work done. This is
- definitely a technical crowd; check your politics at the door.
-
- For more information about the group and how to participate, contact
- the chair, Donn Terry, at donn@hpfcla.fc.hp.com or hplabs!hpfcla!donn.
-
- __________
-
- * UNIXTM is a Registered Trademark of UNIX System Laboratories in
- the United States and other countries.
-
- June, 1990 Standards Update IEEE 1003.1: System services interface
-
-
- - 2 -
-
- Send comments and proposals to the secretary, Keith Stuck, at
- keith@sp7040.uucp. I've made this report a bit more detailed than
- usual in order to give the technical details wider exposure. New
- proposals, and comments on any of the current active proposals or
- issues are welcome.
-
- 2. 1003.1a Status
-
- 1003.1a is the recently completed revision to the 1988 POSIX standard.
- No new interfaces or features were introduced, but the text was
- revised in several ways. The main reason for the revision was to
- prepare the text for balloting as an ISO standard, so the document had
- to be made to look like an ISO standard. This meant adding ISO
- boiler-plate, changing external document references to pretend that
- only standards exist, changing internal cross-references so that
- chapters are renamed sections, and sections are renamed clauses and
- subclauses, changing ``will'' to ``shall,'' etc., ad nauseam. While
- the working group was having fun with all that, they took the
- opportunity to do some cleaning up. They corrected errors, clarified
- unclear language, and changed the function synopses to use ANSI C
- prototypes. The group did make one normative change, which was to
- specify reserved namespaces. This will allow implementations and
- revisions to the standard to define extensions without breaking
- existing, conforming applications. It's messier than you might think.
-
- After four recirculation ballots, IEEE balloting was completed in
- April. Now it has to get through the ISO balloting process. See the
- recent snitch report on 1003.5 for a description of how IEEE and ISO
- balloting is synchronized, and what all of the acronyms mean.
-
- ISO has been balloting 1003.1a as ISO/IEC DIS 9945-1. After the first
- ISO ballot, JTC1 approved 9945-1 for promotion to full IS status.
- This approval was overruled by the ISO Central Secretariat on the
- grounds that the document format was still not satisfactory (still
- haven't caught all of those ``will''s). Rather than publish the
- current document and then immediately revise, ballot, and publish it
- again, it was decided to create a new DIS and to start a second round
- of ISO balloting. This will cause a delay in the publication of the
- international POSIX standard (and hence also the IEEE POSIX.1
- standard). The U.S. Technical Advisory Group (TAG) is responsible for
- generating the U.S. ballot. Assuming that no normative changes are
- introduced by the ISO balloting process, the resulting document will
- be published by IEEE as IEEE Std 1003.1-1990.
-
- June, 1990 Standards Update IEEE 1003.1: System services interface
-
-
- - 3 -
-
- 3. 1003.1b Status
-
- Since 1003.1a is now out of IEEE's hands, the working group spent the
- Utah meeting working on 1003.1b, the first supplement to 1003.1a.
- This will include some corrections and clarifications that didn't make
- it into 1003.1a, but will mainly consist of new interfaces and
- features.
-
- 1003.1b has been in the works for several meetings, so the draft
- already contains a lot of material. The first day was devoted to
- revision of the draft, the rest of the week to considering new
- proposals. The previously announced schedule for 1003.1b specified
- the Utah meeting as the cutoff date for new proposals. Unfortunately,
- some expected proposals were not received, and some that were received
- were not ready for incorporation, so the cutoff was deferred until the
- next meeting, in Danvers, Massachusetts.
-
- Draft 2 of 1003.1b was distributed just before the meeting in Utah.
- Draft 3 should be available before the Danvers meeting. 1003.1b is
- expected to be approved sometime in early 1991, and to be published by
- IEEE as a separate supplement to the IEEE Std 1003.1-1990.
-
- 3.1 New Features in the Current Draft of 1003.1b
-
- Draft 2 of P1003.1b includes a new data interchange format, and new
- interface specifications for symbolic links, environment list access,
- and file-tree walking. These had been proposed and generally accepted
- at previous meetings. Many new issues were raised and discussed.
-
- 3.1.1 Symbolic_Links P1003.1b adds BSD symbolic links to the 1988
- POSIX standard as a new required feature. New interfaces for
- symlink(), readlink(), and lstat() are specified, and the definition
- of pathname resolution is amended to include the handling of symbolic
- links. Implementations may optionally enforce a limit on the number
- of symbolic links that can be tolerated during the resolution of a
- single pathname, for instance to detect loops. The new symbol
- {_POSIX_SYMLOOP} is defined to be the minimum value of such a limit.
- A new error, [ELOOP], is returned if such a limit is exceeded.
- Symbolic links that are encountered in pathname prefixes are always
- resolved. Symbolic links named by the final component of a pathname
- will be resolved or not, depending on the particular interface. By
- default, such symbolic links will be resolved, unless specified
- otherwise. The interfaces that will not resolve symbolic links named
- by pathname arguments are:
-
- + readlink()
- If the pathname argument names a symbolic link, the contents of
- the link will be returned.
-
- + lstat()
- If the pathname argument names a symbolic link, a stat structure
- will be returned for the link itself.
-
- June, 1990 Standards Update IEEE 1003.1: System services interface
-
-
- - 4 -
-
- + unlink()
- If the pathname argument names a symbolic link, the link itself
- will be removed.
-
- + rmdir()
- If the pathname argument names a symbolic link, the link will not
- be followed and the call will fail.
-
- + open()
- Symbolic links are followed, unless both O_CREAT and O_EXCL are
- set. If both O_CREAT and O_EXCL are set, and the pathname
- argument names an existing symbolic link, the link will not be
- followed and the call will fail.
-
- + link()
- If the new pathname names a symbolic link, the link will not be
- followed and the call will fail. If the old pathname names a
- symbolic link, the link will be followed. This is the BSD
- behavior. SVR4.0 does not follow the link in this case, thus
- supporting hard links to symbolic links. The working group felt
- that the SVR4 behavior unnecessarily restricts implementations
- (for instance, those that do not implement symbolic links with
- inodes), and has much more complex semantics.
-
- + rename()
- If the old pathname names a symbolic link, the link will not be
- followed. Instead, the symbolic link itself will be renamed. If
- the new pathname names a symbolic link, it will not be followed.
- Instead, the symbolic link will be removed, and a new hard link
- will be created naming the file that was previously named by the
- old pathname.
-
- The 1988 POSIX standard specifies that if the new pathname names
- an existing file, rename() will fail if the new and old pathnames
- do not either both name directories or both name non-directory
- files. This rule needs to be expanded to include the case of the
- new pathname naming a symbolic link. Should the rename() call
- fail depending on whether or not the symbolic link named by the
- new pathname itself names a directory or a non-directory file?
- This will be resolved at the next meeting.
-
- Symbolic links are not required to have any attributes other than
- their file type and their contents. This is intended to provide the
- simplest semantics and to allow the greatest latitude for
- implementations.
-
- 3.1.2 Other_BSD_Interfaces P1003.1b also includes specifications for
- the following interfaces:
-
- June, 1990 Standards Update IEEE 1003.1: System services interface
-
-
- - 5 -
-
- + fchmod()
-
- + fchown()
-
- + fsync()
-
- + ftruncate()
-
- 3.1.3 Environment_List The ANSI-C standard defines the getenv()
- function to retrieve the value corresponding to a given name in a
- program's environment list, but does not specify the implementation or
- initialization of that list. The 1988 POSIX standard specified the
- traditional list implementation using the external variable environ,
- and specified the initialization of the list by the exec functions.
- In an attempt to extend the set of high-level interfaces to the
- environment list, and to pave the way for the possible eventual
- removal of environ, the working group has included putenv() and
- clearenv() interfaces in 1003.1b. Three problems have been identified
- with these high-level interfaces:
-
- + They cause static data to be shared between the application and
- the implementation. Neither the application nor the
- implementation can easily manage the storage for environment
- "name=value" strings.
-
- + They are not robust. The interactions between the high-level
- interfaces and access via environ is not specified.
-
- + They can't be easily extended to handle multiple lists. There is
- no way to copy a list, or to build a new list for execle() or
- execve().
-
- The putenv() and clearenv() interfaces may be removed from 1003.1b at
- the next meeting if a revised proposal does not appear.
-
- 3.1.4 File_Tree_Walk The 1003.1 working group promised the 1003.2
- group (Shell and Utilities) that a mechanism would be provided for
- walking an directory tree of unbounded depth using any given (non-
- zero) number of free file descriptors. The Berkeley folks have
- implemented a set of high-level interfaces defined by David Korn of
- Bell Labs, and proposed them for inclusion in 1003.1b. These
- interfaces support every option and search order required by the
- 1003.2 commands. The 1003.1 group wants a simpler interface suitable
- for typical application programs, so Keith Bostic will put the
- proposal on a ``weight-reducing diet'' and resubmit it for the next
- draft.
-
- The high-level file-tree walk interfaces can be implemented using only
- the existing 1003.1 interfaces. Since 1003.1 does not define a
- portable way to save and restore file position for a directory and
- cannot hold a file descriptor open for each directory level, the
-
- June, 1990 Standards Update IEEE 1003.1: System services interface
-
-
- - 6 -
-
- implementation must read and save all directory entries each time a
- new directory is visited. This requires only a single file descriptor
- (or whatever resource is used by by opendir()). If the underlying
- system does provide a way to save and restore file position for
- directories, the file-tree walk implementation can use it to reduce
- memory consumption.
-
- There was a discussion about whether it is possible (and preferable)
- to improve the low-level directory interfaces instead of adding new,
- high-level interfaces. Do the high-level interfaces really add new
- functionality for portable applications? Do they belong with the
- low-level operating system interfaces specified in 1003.1?
-
- Walking an unbounded file tree requires an unbounded number of
- directory file positions to be supported using a bounded number of
- file descriptors. Either seekdir() and telldir() are needed, or an
- unbounded number of opendir()'s must use a bounded number of file
- descriptors. The working group has already rejected seekdir() and
- telldir() because they cannot easily be supported on implementations
- that use a non-linear directory format. A prohibition of simple
- implementations of opendir() using file descriptors is also likely to
- be rejected.
-
- The underlying problem is that the orderedness of directory entries
- was implicit in the traditional implementations, but was not made
- fully explicit in 1003.1, partly out of a desire to permit alternate
- implementations (for instance, b-trees). As a result, orderedness
- must now be imposed by the application. On a non-linear directory
- implementation, if positioning is not supported, even opendir() must
- read in the whole directory.
-
- 3.1.5 Data-Interchange_Format The 1988 POSIX standard specified two
- data-interchange formats based on existing utilities. These define
- the data-stream encoding of a sequence of files, together with their
- pathnames and other attributes. The first format is based on tar and
- encodes files as a stream of 512-byte blocks. The second format is
- based on cpio and encodes files as an unblocked byte stream.
-
- The ISO POSIX group (JTC1/SC22/WG15) pointed out that both of these
- formats are incompatible with accepted international and U.S.
- standards. After some arm twisting, the 1003.1 working group agreed
- to devise a new data interchange format based on IS 1001: 1986, which
- is more or less equivalent to ANS X3.27-1987, the familiar ANSI
- labeled tape format.
-
- The current draft of 1003.1b includes the framework for the new
- specification, but a lot more work is needed. Previous meetings
- discussed alternate proposals. The topic has been strangely quiet
- lately, considering the confusion that may be expected when it goes to
- ballot. It wasn't discussed at the Utah meeting at all.
-
- June, 1990 Standards Update IEEE 1003.1: System services interface
-
-
- - 7 -
-
- 3.2 {_POSIX_PATH_MAX}: A Clarification
-
- The 1988 POSIX standard included two conflicting statements regarding
- {PATH_MAX} and {_POSIX_PATH_MAX}: one said that the null was included
- in the count; the other said that the null was excluded. Traditional
- implementations have included the trailing null; some new
- implementations have excluded the null.
-
- One alternative or the other had to be endorsed. The working group
- decided that {_POSIX_PATH_MAX} should not include the trailing null,
- since specifying this will not break currently conforming
- applications.
-
- 3.3 Headers and Name-Space Control
-
- Since 1003.1b is adding many new identifiers to the standard, there
- was discussion about whether new identifiers should be declared in new
- headers, or whether existing headers could be used, with new feature-
- test-macros to control visibility of the additional identifiers. It
- was agreed that although both headers and feature-test macros control
- identifier visibility, their functions are complementary. Headers are
- appropriately used to divide name-spaces horizontally, by
- functionality. Feature-test macros are appropriately used to divide
- name-spaces vertically, by specification level.
-
- With this understanding, the group decided that new identifiers will
- be declared in the ``right place.'' A new header will be created only
- if no existing header is functionally appropriate.
-
- A new feature-test macro will be specified by 1003.1b and subsequent
- revisions: _POSIX_1_SOURCE. This macro takes ordinal values, starting
- with 2 for 1003.1b, and will be incremented by 1 for every subsequent
- revision. If the value is 1, the effect will be the same as if
- _POSIX_SOURCE were defined.
-
- There are two changes here. The new name was used to indicate that
- the macro only controls the visibility of identifiers defined in
- POSIX.1. The usage was changed to allow the value to indicate the
- particular revision or supplement to the standard, rather than having
- to create a new macro each time. This should simplify the
- construction and maintenance of header files.
-
- 3.4 Requests
-
- Two requests were made by vendors trying to support POSIX behavior on
- non-UNIX file systems:
-
- + that {_POSIX_LINK_MAX} be reduced from 6 to 2
-
- + that {_POSIX_PATH_MAX} be reduced from 255 to 252
-
- June, 1990 Standards Update IEEE 1003.1: System services interface
-
-
- - 8 -
-
- Both requests were rejected. Either of these changes could have made
- existing conforming applications non-conforming. Even where the risk
- of breaking applications seemed small, the working group was reluctant
- to set a precedent without a pretty good rationale to protect them
- against similar requests in the future.
-
- 3.5 New Proposals
-
- Five proposals for new interfaces were submitted for inclusion in
- 1003.1b, many of which provoked lively discussion. Some were
- accepted, some were rejected, and others were deferred to allow a
- revised proposal to be submitted or to allow more time for
- consideration.
-
- 3.5.1 seteuid(),_setegid() Bob Lenk and Mike Karels proposed a set
- of changes to the way the effective user and group id's are handled,
- in order to provide better support for setuid/setgid programs.
-
- + Require that all implementations support the functionality of the
- saved user ID and saved group ID. These process attributes are
- set by the exec functions and by privileged calls to setuid() and
- setgid().
-
- + Add seteuid() and setegid() as new functions that change only the
- effective user ID and effective group ID, respectively. A change
- is allowed if the proposed new user/group ID is the same as
- either the real user/group ID or the saved user/group ID.
-
- + Redefine the {_POSIX_SAVED_IDS} option to apply only to non-
- privileged calls to setuid() and setgid().
-
- This proposal has general support in the working group, and will be
- included in the next draft of 1003.1b.
-
- The discussion of this proposal led to a general lament about how
- unclear the group model is in the 1988 POSIX standard, perhaps the
- result of a hasty marriage between the System V and BSD models. At
- the next meeting, the working group intends to add new text to
- P1003.1b to clarify the relation between the effective group ID and
- the supplementary group list.
-
- 3.5.2 Magnetic_Tape_Support The 1003.10 working group
- (Supercomputing Profiles) proposed new interfaces to support basic
- controller functions for magnetic tape drives, based on the ioctl()
- commands supported in 4.3BSD. Although support for these interfaces
- would be optional in 1003.1b, the working group decided that the
- functions should be further specified according to whether they are:
-
- + required for all types of tape drives;
-
- June, 1990 Standards Update IEEE 1003.1: System services interface
-
-
- - 9 -
-
- + required only for 9-track tape drives;
-
- + required only for cartridge tape drives; or
-
- + optional on all types of tape drives.
-
- The proposal needed further revision, but was generally supported by
- the working group.
-
- The submitted proposal also included interfaces for mounting labeled
- tape volumes. These were considered to be inappropriate for inclusion
- at this time and will be deferred until a later revision of the
- standard.
-
- 3.5.3 Checkpoint/Restart The 1003.10 working group also proposed new
- (optional) interfaces for checkpointing and restarting processes.
- This proposal is based on two existing implementations. The
- interfaces are intended to protect very-long-running applications from
- both scheduled shutdowns and unexpected failures of the system.
-
- The 1003.1 working group was not happy to have to deal with this and
- had lots of questions. Were programming interfaces for portable
- applications really needed, or was a command interface sufficient?
- How much state needed to be saved in the checkpoint? What if the
- processes depended on additional state information that was not in the
- checkpoint, such as file data or the states of other communicating
- processes or devices? In this case, the restart would only be
- successful if this additional state had not changed since the
- checkpoint. How could such changes be detected or prevented? What is
- the set of interfaces that an application can use and be sure that it
- can be checkpointed and restarted successfully, without dependencies
- on additional state? Should applications have a mechanism for
- checkpointing themselves, or for blocking an external request that
- they be checkpointed?
-
- Because a checkpoint/restart mechanism will have a major impact on
- implementations, and the requirements are not yet clear, the working
- group was unwilling to endorse the current proposal. A task force
- made up of representatives of the 1003.1 and 1003.10 working groups
- will be created to clarify the requirements and revise the proposal.
-
- This proposal is going to need a lot more discussion, so checkpoint
- restart interfaces will almost certainly not be included in P1003.1b,
- but they may be adopted in a subsequent revision.
-
- 3.5.4 Messaging The UniForum proposal for new messaging interfaces
- has been before the 1003.1 working group for a couple of meetings now.
- The proposed interfaces are intended as replacements for the message
- catalog interfaces specified in XPG3, and differ from those in several
- ways (since the discussion was fairly contentious, I'll try to be
- objective):
-
- June, 1990 Standards Update IEEE 1003.1: System services interface
-
-
- - 10 -
-
- + The XPG3 interfaces identify a message by the triple: <catalog
- name, set ID, msg ID>, where catalog name is a file name, and set
- ID and msg ID are integers. The UniForum interfaces identify a
- message by the triple: <locale name, domain name, message name>,
- where locale name, domain name, and message name are all strings.
- The locale for messages is specified by the new LC_MESSAGES
- category of the locale. Advocates of the UniForum proposal claim
- that string identifiers are easier to use and are more robust
- against errors during application development and maintenance.
-
- + In the XPG3 scheme, each message catalog is an ordinary file.
- Message catalogs must be specified by filename and explicitly
- opened before messages can be retrieved. The NLSPATH environment
- variable provides a search path for message catalogs that can be
- parameterized by (among other things) the language, territory,
- and codeset fields of the LANG environment variable. In the
- UniForum scheme, groups of messages are specified by an abstract
- ``domain.'' A default domain can be set to control message
- accesses, or the domain can be explicitly specified for an
- individual message access. Advocates of the UniForum proposal
- claim that the binding of message catalogs to files unnecessarily
- restricts implementations and imposes a more complex interface on
- application developers.
-
- + The XPG3 interface includes an additional string argument that is
- returned in case no message specified by <set ID, msg ID> can be
- retrieved from the message catalog. In the UniForum proposal,
- the message name itself is returned if the message cannot be
- found. Advocates of the UniForum proposal point out that the
- message name string makes a separate, ``default'' message string
- unnecessary.
-
- In addition, the UniForum proposal includes a specification of the
- message source file format that differs from the format specified in
- XPG3.
-
- + In the XPG3 format, message strings are implicitly delimited: at
- the beginning by the preceding message ID followed by a single
- space or tab character, and at the end by an unescaped newline.
- In the UniForum format, all strings, including domain names,
- message ID's, and message strings, are explicitly delimited by
- double quotes ("). Adjacent strings separated by white-space
- characters are concatenated. Advocates of the UniForum proposal
- claim that the new format provides better support for multi-line
- strings and for leading and trailing white-space characters in
- strings.
-
- + In the XPG3 format, the message ID and its corresponding message
- string are implicitly determined by their position on a source
- line. In the UniForum format, explicit directives are provided
- for message ID's and message strings. Advocates of the UniForum
-
- June, 1990 Standards Update IEEE 1003.1: System services interface
-
-
- - 11 -
-
- proposal claim that the new format is extensible. New attributes
- may be added to message entries, such as screen coordinates or
- font size.
-
- + The XPG3 format includes directives for deleting individual
- messages and sets of messages, and the associated gencat utility
- takes no switches. In the UniForum proposal, all deletion
- semantics are provided by switches on the associated gentext
- utility.
-
- There was much discussion of the interfaces; less about the source
- file format. The most divisive issue was whether string message ID's
- are preferable to numeric message ID's. Among those who felt that the
- new interfaces are better, there was disagreement about whether the
- advantages outweighed the cost of conversion for applications and
- implementations based on the XPG3 interfaces. The rationale
- accompanying the UniForum proposal described several ways to convert
- applications from the XPG3 interfaces to the proposed new interfaces.
-
- The working group asked X/Open to submit the XPG3 messaging interfaces
- as an alternate proposal, since they represent existing practice, and
- X/Open has agreed to do so. X/Open has said that they will follow
- POSIX if POSIX endorses a different interface. The decision regarding
- which, if any, messaging proposal to include in 1003.1b will be made
- at the POSIX meeting in Danvers.
-
- It's hard to predict the fate of this proposal. The UniForum proposal
- represents the consensus of one of the leading internationalization
- working groups and is reported to have some support within X/Open. On
- the other hand, the POSIX working groups are obliged to respect
- existing practice. Watch this space.
-
- 3.5.5 /dev/stdin,_/dev/fd/n,_etc. There was an unofficial proposal
- from members of the 1003.2 working group that open() be extended to
- recognize the special strings "/dev/stdin", "/dev/stdout",
- "/dev/stderr", and "/dev/fd/n", and return a new file descriptor
- dup()'ed from STDIN_FILENO, STDOUT_FILENO, STDERR_FILENO, or file
- descriptor n, respectively. This proposal was intended to allow
- simplified command line parsing, by eliminating special casing for
- ``-'' and ``--'' arguments. The proposal was rejected after a short
- exploration of the possible semantics of these pathnames when used
- with link(), rename(), etc..
-
- 4. Conclusion
-
- As you can see, there's a lot going on. Even though most of the
- attention has shifted to other working groups, the 1003.1 group is
- busy revising and extending the 1988 standard. The group is small
- now, by POSIX standards, but their work is as important as ever.
-
- June, 1990 Standards Update IEEE 1003.1: System services interface
-
- Volume-Number: Volume 20, Number 56
-
- shar.1003.1.8174
- echo 1003.12
- cat >1003.12 <<'shar.1003.12.8174'
- From uucp@tic.com Thu Jun 21 18:02:12 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA26630; Thu, 21 Jun 90 18:02:12 -0400
- Posted-Date: 21 Jun 90 19:47:14 GMT
- Received: by cs.utexas.edu (5.64/1.63)
- id AA11445; Thu, 21 Jun 90 17:02:06 -0500
- Received: by longway.tic.com (4.22/tic.1.2)
- id AA18884; Thu, 21 Jun 90 16:36:44 cdt
- From: <jsh@usenix.org>
- Newsgroups: comp.std.unix
- Subject: Standards Update, IEEE 1003.12: PII
- Message-Id: <375@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: std-unix@uunet.uu.net
- Date: 21 Jun 90 19:47:14 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
-
- An Update on UNIX*-Related Standards Activities
-
- May 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- IEEE 1003.12: PII
-
- Andy Nicholson <droid@earth.cray.com> reports on the April 23-27
- meeting in Salt Lake City, UT:
-
- Introduction
-
- For starters, we've had some significant turnover. [Editor:
- Including, you'll note, Steve Head, our former, fine dot 12 snitch.
- Thanks for diving in, Andy.] We are now down to five participants who
- were present a year ago, are on our third AT&T representative, and an
- HP representative has permanently left the working group. Despite all
- this, the group is beginning to make rapid advances on both the
- Simplified (SNI) and Detailed (DNI) network interfaces. This
- meeting's progress is sketched below.
-
- Overview of the Work We're Doing
-
- The dot 12 committee is working on three projects: Simplified Network
- interface (SNI), Detailed Network Interface (DNI), and Data
- Representation Interface (DRI). Work on DRI is being delayed until
- SNI and DNI are well along. DNI is a protocol-independent interface
- to network services that allows access to protocol-dependent features
- in a protocol-independent manner. DNI is meant to provide a complete
- interface to everything you might expect to be able to do with
- networking services. DNI is comparable to Berkeley Sockets or AT&T's
- TLI, and we plan that anything that can be accomplished with those
- interfaces will be subsumed by DNI.
-
- The idea behind SNI is that many applications will not require
- ``detailed'' access to networking services. SNI gives a ``stdio''
- type of interface for networking that combines common groupings of
- procedures, eliminates access protocol-dependent features, and is just
- plain easier to use. Applications that use SNI aren't necessarily
- simple, they just don't need DNI's detailed access to networking
- services.
-
- __________
-
- * UNIX is a registered trademark of AT&T in the U.S. and other
- countries.
-
- May 1990 Standards Update IEEE 1003.12: PII
-
- - 2 -
-
- Simple Network Interface
-
- We started the week discussing the SNI interface. Norm Smith, from
- Unisys, had intended to bring an alternate SNI proposal to this
- meeting, but his group at Unisys decided to work with the current one.
- Irene Hu, from DEC, says she may yet offer an alternate proposal.
-
- I presented a paper, prepared from previous minutes, which gathered up
- some deferred issues relating to SNI and we resolved some of them.
- For example, we added some explicit goals for SNI that everyone seemed
- to have accepted implicitly, but were never made official.
-
- We also considered creating a formal definition of SNI functionality,
- to help us determine whether any particular function should be
- included, but decided it would be more efficient to keep deliberating
- each case individually. We'll record the rationale for each as part
- of the standard document to help us avoid and respond to ballot
- objections.
-
- + SNI functionality
- A paper by Tim Kirby (who works with me at Cray Research)
- prompted the group to redefine a function call. Sni_recv(), was
- defined to discard excess data in a datagram when the buffer
- offered by an application isn't large enough. The new version of
- Sni_recv(), allows an application either to discard excess data
- or to perform multiple sni_recv() calls to read it all. It also
- allows applications to discard datagrams without reading them at
- all. Here, I think the group has noticeably extended the power
- of the interface without sacrificing efficiency.
-
- + Kernel objects
- Because SNI endpoints may not be kernel objects, we need to
- define semantics and interfaces that will allow SNI endpoints to
- survive exec(). Unfortunately, we disagree on the semantics of
- the endpoint-preservation procedures. Should multiple copies of
- the same endpoint exist in different processes' address spaces,
- as happens with fork() and exec()? Implementing the protocol
- stack in a user library creates multiple copies of state
- information for the same endpoint, and it may be impossible to
- keep them synchronized.
-
- Some of us (Keith Sklower, from Berkeley, the author of the SNI
- document, and I) want to restrict endpoint semantics so that only
- one process may have a copy of an SNI endpoint; others (Irene and
- Norm) disagree and wish to allow multiple copies of SNI endpoints
- where the programmer wishes.
-
- May 1990 Standards Update IEEE 1003.12: PII
-
- - 3 -
-
- Detailed Network Interface
-
- We discussed DNI procedures in detail for the first time and found
- tentative agreement on most of the many issues raised. Mike Karels,
- from Berkeley's Computer Science Research Group, presented an outline
- of required functionality. After discussing it, we agreed to make DNI
- endpoints POSIX file descriptors (as returned by open()) until we see
- a compelling counter-argument. I'll challenge you to offer one.
-
- On Wednesday, Irene gave an overview of XTI. During the presentation,
- Torez Hiley, our new attendee from ATT, told us that XTI is being
- revised: input from vendors using the Berkeley socket interface is
- prompting the addition of many features. Torez will report on the
- upcoming revision at the July meeting. Where sockets and XTI/TLI
- differ, the best solution is not clear. Moreover, some features are
- absent or inadequately supported in both interfaces. Here, we have a
- lot of work to do and are just getting started. We're eager to hear
- whether the new XTI solves any of our problems.
-
- May 1990 Standards Update IEEE 1003.12: PII
-
-
- Volume-Number: Volume 20, Number 32
-
- shar.1003.12.8174
- echo 1003.14
- cat >1003.14 <<'shar.1003.14.8174'
- From uucp@tic.com Sat Jun 23 14:44:47 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA19242; Sat, 23 Jun 90 14:44:47 -0400
- Posted-Date: 23 Jun 90 12:28:11 GMT
- Received: by cs.utexas.edu (5.64/1.63)
- id AA17482; Sat, 23 Jun 90 10:02:16 -0500
- Received: by longway.tic.com (4.22/tic.1.2)
- id AA24922; Sat, 23 Jun 90 09:26:07 cdt
- From: <jsh@usenix.org>
- Newsgroups: comp.std.unix
- Subject: Standards Update, IEEE 1003.14: Multiprocessing
- Message-Id: <381@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: std-unix@uunet.uu.net
- Date: 23 Jun 90 12:28:11 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
-
- An Update on UNIX*-Related Standards Activities
-
- June, 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- IEEE 1003.14: Multiprocessing
-
- Bill Cox <bill@attunix.att.com> reports on the April 23-27 meeting in
- Salt Lake City, UT: The POSIX Multiprocessing Study Group had its
- first official meeting as P1003.14 in Utah, where the SEC approved its
- Project Authorization Request (PAR) for a Multiprocessing Execution
- Environment Profile. Multiprocessing systems have become cost-
- effective means for providing computing power, but with the advantages
- have some specific concerns that need to be addressed at the interface
- level. The goal of this work is to try to make POSIX safe for
- multiprocessing; a secondary goal is to try to make POSIX hospitable
- for multiprocessing. POSIX working groups do not necessarily share
- the concerns of the implementors and users of multiprocessing systems.
-
- Bob Knighten (Encore) is the Chair, Bill Cox (AT&T UNIX Software
- Operation) is Secretary, and Dave Plauger (Alliant) is the Technical
- Editor. Officers must have a commitment of support from their
- employers, to ensure that they can attend working group meetings and
- devote necessary time to the purposes of the working group. 16 people
- attended the group meetings.
-
- People interested in .4A (threads) have tended to be interested in .14
- and vice versa. Many .14 members that have been meeting with
- P1003.4/.4A see substantial problems with pthreads in a multiprocessor
- environment, and I know at least eight people working on .4A that want
- to come work in .14.
-
- The working group designated one official liaison to .4A, who was
- joined by two other tentative volunteers. We will also establish
- liaisons with .1, .6, .7, .8, .10, and .12.
-
- During the week, we spent time in three areas.
-
- 1. We clarified the group's work items, and started work on the
- most important, the Application Environment Profile. (An AEP
- may specify relevant portions of other POSIX working groups'
- work, make choices where options are permitted, and specify
- behavior that a [draft] standard may have left undefined or
- unspecified.)
-
- __________
-
- * UNIX is a registered trademark of AT&T in the U.S. and other
- countries.
-
- June, 1990 Standards Update IEEE 1003.14: Multiprocessing
-
-
- - 2 -
-
- 2. We discussed current conventional wisdom on multiprocessing.
- The discussions centered around presentations by BBN, Cray,
- Encore, AT&T USO, and Alliant on lessons they've learned.
-
- 3. We created two small groups.
-
- The first began work on high-level requirements placed on
- pthreads by multiprocessing. Attendees included Rick Greer
- (Interactive), Mary Weeks (Sun), and Bill Cox (AT&T USO).
-
- Here are some requirements we feel strongly about:
-
- + A library implementation of ``user-level threads'' is
- vitally important. User-level threads often must be
- multiplexed onto kernel-supported
- objects/processes/threads, largely for performance reasons.
- These kernel-supported objects, etc, are sometimes called
- ``virtual processors,'' because they support an abstraction
- closer to that of a physical processor, with
- interrupts/signals, and a significant amount of state.
-
- + The formal memory model of P1003.4/D9 section 13.1 must
- apply to .4A. This model defines the semantics of memory
- interaction that should be preserved in a multithreaded or
- multiprocessing environment.
-
- + Global threads scheduling makes little sense in a
- multiprocessor, though such scheduling could be useful as a
- hint (Like C's register declarations if you don't have
- enough registers.) Global policy is difficult to implement
- in a multiplexed thread environment.
-
- + use of attribute structures for mutual exclusion variables
- (in particular, for scheduling hints)
-
- + Locks shouldn't be opaque, and programmers should be able
- to statically initialize them. The latter is important so
- that locks can be part of data structures, and not require
- time-consuming dynamic allocation and initialization.
-
- + There must be only one set of libraries. There are
- performance reasons to have single-threaded libraries,
- i.e., libraries that are not thread-aware, for a
- uniprocessor or single-threaded applications. The group
- believes that the cost of maintaining such libraries is
- sufficiently high that a non-reentrant library or set of
- libraries should not be required.
-
- June, 1990 Standards Update IEEE 1003.14: Multiprocessing
-
-
- - 3 -
-
- The other group began work on the AEP itself.
-
- Members of this small group, and their responsibilities,
- included
-
- + Dave Plauger (Alliant) - skeleton for the document,
-
- + Frank Lawlor (IBM) - checkpoint restart, review, and
- liaison with .10 and .7,
-
- + James Gibson (BBN) - review and liason with .2,
-
- + Bob Knighten (Encore) - review and liason with .4, and
-
- + Tom Weaver (IBM) - review and liason with .1 and .6.
-
- This group identified several areas of concern:
-
- + microtasking models
-
- + checkpoint, snapshots, and core dump format/synchronization
-
- + a general programming model
-
- + dividing the ``reading list'' (other P1003 standards and
- drafts)
-
- + determining focus (are we dealing with portability for
- application writers, users, and/or administrators?)
-
- + standardizing system services
-
- A sketch of the planned document includes:
-
- + reference to TIMS
-
- + multithreaded applications (.4A)
-
- + HLL parallel applications (PCF FORTRAN, parallel C)
-
- + IPC
-
- June, 1990 Standards Update IEEE 1003.14: Multiprocessing
-
- Volume-Number: Volume 20, Number 44
-
- shar.1003.14.8174
- echo 1003.2
- cat >1003.2 <<'shar.1003.2.8174'
- From uucp@tic.com Thu Jun 21 18:03:02 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA26982; Thu, 21 Jun 90 18:03:02 -0400
- Posted-Date: 21 Jun 90 20:17:50 GMT
- Received: by cs.utexas.edu (5.64/1.63)
- id AA11544; Thu, 21 Jun 90 17:02:52 -0500
- Received: by longway.tic.com (4.22/tic.1.2)
- id AA18940; Thu, 21 Jun 90 16:39:41 cdt
- From: <jsh@usenix.org>
- Newsgroups: comp.std.unix
- Subject: Standards Update, IEEE 1003.2: Shell and tools
- Message-Id: <378@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: std-unix@uunet.uu.net
- Date: 21 Jun 90 20:17:50 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
- An Update on UNIX*-Related Standards Activities
-
- June 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- IEEE 1003.2: Shell and tools
-
- Randall Howard <rand@mks.com> reports on the April 23-27 meeting in
- Salt Lake City, UT:
-
- Background on POSIX.2
-
- The POSIX.2 standard deals with the shell programming language and
- utilities. Currently, it is divided into two pieces:
-
- + POSIX.2, the base standard, deals with the basic shell
- programming language and a set of utilities required for
- application portability. Application portability essentially
- means portability of shell scripts and thus excludes most
- features that might be considered interactive. In an analogy to
- the ANSI C standard, the POSIX.2 shell command language is the
- counterpart to the C programming language, while the utilities
- play, roughly, the role of the C library. POSIX.2 also
- standardizes command-line and function interfaces related to
- certain POSIX.2 utilities (e.g., popen, regular expressions,
- etc.) This document is also known as ``Dot 2 Classic.''
-
- + POSIX.2a, the User Portability Extension or UPE, is a supplement
- to the base POSIX.2 standard; it will eventually be an optional
- chapter of a future draft of the base document. The UPE
- standardizes commands, such as screen editors, that might not
- appear in shell scripts but are important enough that users must
- learn them on any real system. It is essentially an interactive
- standard that attempts to reduce retraining costs incurred by
- system-to-system variation.
-
- Some utilities, have interactive as well as non-interactive
- features. In such cases, the UPE defines extensions from the
- base POSIX.2 utility. An example is the shell, for which the UPE
- defines job control, history, and aliases. Features used both
- interactively and in scripts tend to be defined in the base
- standard.
-
- __________
-
- * UNIX is a registered trademark of AT&T in the U.S. and other
- countries.
-
- June 1990 Standards Update IEEE 1003.2: Shell and tools
-
-
- - 2 -
-
- Together Dot 2 Classic and the UPE will make up the International
- Standards Organization's IS 9945/2 - the second volume of the proposed
- ISO four-volume standard related to POSIX.
-
- In addition to providing current information about the activities of
- the Working and Balloting Groups for POSIX.2, a special topic of focus
- will be chosen for each report. Therefore, the reader is referred to
- earlier reports for information on such topics as the history of the
- Shell Wars and the controversial scope of the UPE. The next section
- talks about the functions, rather than utilities, that are found with
- POSIX.2.
-
- The POSIX.2 API Functions
-
- Perhaps it will come as a surprise to many readers that the POSIX
- Shell and Utilities standard also contains specifications for about
- fourteen new or extended C function bindings -- in effect, its own API
- extending the POSIX.1 bindings -- as follows:
-
- confstr(), sysconf() The first function was created to provide
- string-valued, configuration-specific values such as the
- default setting of the PATH environment variable. The
- second extends the POSIX.1 function of the same name with
- numeric-valued configuration information such as the
- largest scale value in the bc utility and the
- implementation's line length restriction.
-
- fnmatch() This functional interface implements the form of pattern
- matching used by file-name generation (glob) in the shell,
- case statements in the shell, and the -name option of the
- find utility.
-
- getopt() This functional interface provides a standard utility
- argument parser that enforces the ``standard utility
- syntax'' guidelines and might be used to implement the
- getopts utility from POSIX.2.
-
- glob(), globfree() This set of functions does shell-style file-name
- generation and presumably calls the fnmatch() function.
-
- popen(), pclose() This pair of functions, which is a part of the
- standard I/O package on conventional UNIX systems,
- provides the ability to communicate through pipes to
- another process by executing a string in the POSIX.2 shell
- language.
-
- regexec(), regcomp() This set of routines provides support for both
- the Basic and Extended Regular Expressions defined in
- POSIX.2, including full internationalization support.
-
- June 1990 Standards Update IEEE 1003.2: Shell and tools
-
-
- - 3 -
-
- wordexp(), wordfree() This set of routines provides a mechanism for
- an application to use word expansion (parameter expansion)
- that is compatible with the POSIX.2 shell language.
- Although most implementations of this routine will
- normally call the shell, it is (at least conceptually)
- possible that the shell be implemented to call these
- routines for word expansion.
-
- system() This ``classical'' function executes a command written in
- shell language.
-
- All of these functions form part of an optional C binding to POSIX.2
- and it is expected that the soon-to-be-released, draft version of the
- NIST FIPS will make this ``optional'' functional interface mandatory
- for US government procurements. Other language-binding working
- groups, such as those exploring Ada and FORTRAN, are presumably
- encouraged to add their own optional bindings if they so wish.
-
- Although the inclusion of these functions seems to be a little out of
- place in a shell-and-tools standard, there is some rationale for this.
- In fact, when POSIX consisted only of POSIX.1, the early attempts to
- define system() and popen() made apparent the need to completely
- specify the shell language in which the argument string to these
- functions was written. That, in turn, along with the desire to
- standardize the classical UNIX utility set, led to the creation of
- POSIX.2 as the first offshoot group in the POSIX family of standards.
- shar.1003.2.8174
- echo 1003.3
- cat >1003.3 <<'shar.1003.3.8174'
- From uucp@tic.com Thu Jun 21 18:02:47 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA26860; Thu, 21 Jun 90 18:02:47 -0400
- Posted-Date: 21 Jun 90 20:06:46 GMT
- Received: by cs.utexas.edu (5.64/1.63)
- id AA11531; Thu, 21 Jun 90 17:02:41 -0500
- Received: by longway.tic.com (4.22/tic.1.2)
- id AA18922; Thu, 21 Jun 90 16:38:51 cdt
- From: <jsh@usenix.org>
- Newsgroups: comp.std.unix
- Subject: Standards Update, IEEE 1003.3: Test Methods
- Message-Id: <377@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: std-unix@uunet.uu.net
- Date: 21 Jun 90 20:06:46 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
- An Update on UNIX*-Related Standards Activities
-
- June, 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- IEEE 1003.3: Test Methods
-
- Doris Lebovits <lebovits@attunix.att.com> reports on the April 23-27
- meeting in Salt Lake City, UT:
-
- Dot three's job is to do test methods for all of the other 1003
- standards. The group's work, whose first parts are now in ballot,
- specifies the requirements for OS conformance testing for our industry
- and for NIST. This makes what the balloting group and technical
- reviewers are doing, and their schedules, worth watching. Pay
- attention, also, to what comes out of the Steering Committee on
- Conformance Testing (SCCT). Their projects and decisions will be
- interesting and important.
-
- This was the working group's sixteenth meeting. As usual, we reviewed
- the ballot status of P1003.1 test methods, worked on P1003.2 test
- methods, and reviewed steering committee activities. As before, each
- morning we did technical reviews of parts I and II; afternoons were
- spent writing assertions for part III. Participants from the usual
- companies attended. (AT&T, NIST, OSF, Mindcraft, IBM, DEC, HP, Data
- General, Cray Research, Unisys, Perennial, and Unisoft Ltd.)
-
- Document structure and some new PARs
-
- Currently, our evolving document has two parts: Part I is generic test
- methods; Part II is test methods for measuring P1003.1 conformance,
- including test assertions; and Part III contains test methods and
- assertions for measuring P1003.2 conformance. (As other P1003
- standards evolve, they will become separate activities in the working
- group's schedule.)
-
- After the ballot, each part will become a separate standard. Part I
- will be published as IEEE P1003.3; Part II as IEEE P1003.3.1; and Part
- III as IEEE P1003.3.2. To this end, we developed and submitted three
- new PARs to the Standards Executive Committee (SEC). The PAR for
- P1003.3 lets Part I apply to all TCOS standards (i.e., POSIX). The
- PAR for P1003.3.1 lets Part II include test methods for P1003.1 and
- P1003.1a. The PAR for P1003.3.2 lets Part III include test methods
- for P1003.2.
-
- __________
-
- * UNIX is a registered trademark of AT&T in the U.S. and other
- countries.
-
- June, 1990 Standards Update IEEE 1003.3: Test Methods
-
-
- - 2 -
-
- Ballot status
-
- Draft 11 of the current ballot, which was re-circulated to the
- (approximately) ninety-member balloting group late in February, closed
- balloting March 23. Of the 65 respondents, 29 approved, 17
- disapproved, and 19 abstained. This meets the two-thirds response
- requirement, but falls short of the needed two-thirds approval.
- Another re-circulation will probably take place in Fall, 1990.
-
- P1003.2 verification
-
- This was our fourth meeting working on a verification standard for the
- P1003.2 standard. The assertion writing and review were done in small
- groups. Some of the assertions were based upon P1003.2 Draft 9. This
- group needs help from the P1003.2 working group in writing test
- assertions, but no formal arrangement is in place yet to provide it.
-
- Officers for the P1003.2 Test Methods activities are: Ray Wilkes
- (Unisys), Chair; Lowell Johnson (Unisys) Secretary; and Andrew Twigger
- (Unisoft Ltd), Technical Editor.
-
- Steering Committee on Conformance Testing (SCCT)
-
- The test-methods steering committee is supposed to alleviate the
- increasing dot-three work load all the other, proliferating groups are
- creating. Their job is coordinating the activities of all test-
- methods groups, monitoring their conformance to test methods, and
- writing Project Authorization Requests (PARs). Currently, its members
- are Roger Martin (NIST, Steering Committee Chair), Anita Mundkur (HP),
- Andrew Twigger (Unisoft Ltd), Bruce Weiner (Mindcraft), and Lowell
- Johnson (Unisys), but membership will be dynamic, Right now, this
- committee is documenting procedures. Roger Martin is also clarifying
- which standards the working group will address. The Technical
- Reviewers will review this work sometime before the next meeting.
-
- June, 1990 Standards Update IEEE 1003.3: Test Methods
-
-
- Volume-Number: Volume 20, Number 34
-
- shar.1003.3.8174
- echo 1003.4
- cat >1003.4 <<'shar.1003.4.8174'
- From jsq@longway.tic.com Sat May 19 15:44:38 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA28156; Sat, 19 May 90 15:44:38 -0400
- Posted-Date: 19 May 90 19:34:52 GMT
- Received: by cs.utexas.edu (5.61/1.62)
- id AA06978; Sat, 19 May 90 14:44:34 -0500
- Received: by longway.tic.com (4.22/4.16)
- id AA11134; Sat, 19 May 90 14:35:24 cdt
- From: <usenix.org!jsh@longway.tic.com>
- Newsgroups: comp.std.unix
- Subject: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <695@longway.TIC.COM>
- Sender: std-unix@longway.tic.com
- Reply-To: std-unix@uunet.uu.net
- Date: 19 May 90 19:34:52 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
-
- An Update on UNIX*-Related Standards Activities
-
- May 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- IEEE 1003.4: Real-time Extensions
-
- Rick Greer <rick@ism.isc.com> reports on the April 23-27 meeting in
- Salt Lake City, UT:
-
- 1003.4
-
- The .4 ballots went out on schedule, and most came back on schedule as
- well. We (barely) got the required 75% response, of which 43%
- approved of the draft as it stood. The small-group leaders are
- currently working to resolve the objections and will report back at
- Danvers, in July.
-
- 1003.4a
-
- Most of the work at Snowbird centered around threads (.4a). Two
- alternatives to the pthreads proposal were presented at the meeting:
- ``strands'', from John Zolnowsky of Sun, defined a minimal set of
- interfaces for multi-threaded applications; ``VP'', from Paul Borman
- of Cray, added a ``virtual processor'' layer to the pthreads
- specification, which made some multiprocessor (MP) features visible to
- applications.
-
- The primary MP hardware feature that Paul's VP proposal makes visible
- to the pthreads environment is the ability to write your own spin
- loops and expect them to work. One could, for example, have one
- thread continuously reading an in-core data base while another thread
- updates it. On an MP system, it might be more efficient to code this
- without using a mutex, although doing so on a uni-processor with a
- co-routine threads package is an absolute disaster. The new
- multiprocessor group, 1003.16, is looking into this and similar
- problems, and will probably suggest that .4a include some sort of
- system-wide attribute structure that one can check when writing
- programs that depend heavily on concurrent execution of threads.
-
- After a week's discussion (often a euphemism for argument), we settled
- into a compromise position not that far from where we started --
- pthreads. All this work without much net change was frustrating, but
-
- __________
-
- * UNIX is a registered trademark of AT&T in the U.S. and other
- countries.
-
- May 1990 Standards Update IEEE 1003.4: Real-time Extensions
-
-
- - 2 -
-
- probably unavoidable. Until fairly recently most of the committee was
- busy getting the .4 draft ready for balloting. Lacking enough time to
- have studied threads carefully, members were unwilling to accept the
- small group's conclusions before investigating some alternatives for
- themselves. Still, some progress was made. The most important was a
- more comprehensive definition of signal behavior in multi-threaded
- programs.
-
- 1003.14
-
- On the last day, a first attempt at a real-time application
- environment profile (AEP) was presented. This PAR will be an
- excellent, practical test of AEPs. Real-time applications are likely
- to vary wildly in the subsets of .4's rich features that they require.
- Some worry that the real-time AEP will force embedded systems that
- need only one or two .4 features to incorporate others just to adhere
- to the standard. The problem this poses is not just storage space
- wasted by unused code, but the expense of verifying that this extra
- code will never get in the way of the application. The group will be
- wrestling with these and similar problems in the months to come.
-
- May 1990 Standards Update IEEE 1003.4: Real-time Extensions
-
-
- Volume-Number: Volume 20, Number 5
-
- shar.1003.4.8174
- echo 1003.4.033
- cat >1003.4.033 <<'shar.1003.4.033.8174'
- From uucp@tic.com Thu Jun 21 18:02:29 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA26744; Thu, 21 Jun 90 18:02:29 -0400
- Posted-Date: 21 Jun 90 19:57:52 GMT
- Received: by cs.utexas.edu (5.64/1.63)
- id AA11487; Thu, 21 Jun 90 17:02:19 -0500
- Received: by longway.tic.com (4.22/tic.1.2)
- id AA18902; Thu, 21 Jun 90 16:37:43 cdt
- From: <jsh@usenix.org>
- Newsgroups: comp.std.unix
- Subject: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <376@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: std-unix@uunet.uu.net
- Date: 21 Jun 90 19:57:52 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
- From: <jsh@usenix.org>
-
-
- An Update on UNIX*-Related Standards Activities
-
- June 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- IEEE 1003.4: Real-time Extensions
-
- John Gertwagen <jag@ism.isc.com> reports on the April 23-27 meeting in
- Salt Lake City, UT:
-
- 1. Administrivia
-
- P1003 met in Salt Lake City this time. Actually, it was at Snowbird
- Lodge, south of and well above the city. It was spring in Salt Lake
- but still winter in the mountains. (Wish I skied.) The real-time
- meetings drew 68 people the first day, and averaged around 40 all
- week. If some skiers hadn't deserted each day, we would have had
- more.
-
- 2. .4 Balloting
-
- Over 200 people joined the balloting group for P1003.4, Draft 9. The
- first ballot closed in mid-March and 75% of balloters returned their
- ballots within a day or two of the official deadline, setting a new
- record! 43% of these voted ``Yes'' on the first round, about average
- for POSIX ballots.
-
- Lack of time and logistics problems meant little ballot feedback by
- meeting-time, (shame on those who didn't submit their ballots
- electronically!) but a few issues surfaced. Several objected to
- having binary semaphores only in the path namespace and not also in
- shared memory, where they could use simple test-and-set calls, and not
- time-consuming system calls. There's value providing a common
- interface for both of these and for other ``synchronization objects.''
-
- There were also objections to having ``events'' when there are
- ``fixed'' signals in System V, Release 4. The technical reviewer for
- events will try to make SVR4 signals meet real-time requirements.
- (Not too long ago, there were strong objections to changing signals.
- There may still be protests over adding real-time-required
- determinism.)
-
- __________
-
- * UNIX is a registered trademark of AT&T in the U.S. and other
- countries.
-
- June 1990 Standards Update IEEE 1003.4: Real-time Extensions
-
-
- - 2 -
-
- 3. Current Work
-
- With .4 in limbo, the working group got on with Threads (.4a),
- Language Independent Bindings (.4b), and Real-time Application
- Environment Profiles (.14). Threads got the most attention.
- (Surprised?) Despite this, or perhaps because of it, the other two
- drafts saw significant progress.
-
- Rick Greer has reviewed a lot of the threads work, so I'll briefly
- mention what's going on in .4b and .14, give you some personal views
- on threads, and then amplify on areas where our editor, Jeff Haemer,
- was recently raked over the coals.
-
- 4. AEP
-
- At first, the real-time AEP small group had some trouble focusing.
- They've identified two fairly easy targets, essentially minimum and
- maximum configurations, and now seek proposals for intermediate
- specifications.
-
- In Utah, the group came up with a fairly complete specification for
- embedded systems, and reviewed it with P1003.0 -- the POSIX Guide
- group that is the driving force in defining AEP's. One interesting
- issue surfaced during the review: for embedded systems, the AEP group
- wants to exclude interfaces of .4 and .1 that aren't needed! Dot zero
- hadn't thought of that before. Resolving this should set an
- interesting precedent.
-
- 5. Language-Independent Bindings
-
- The people doing this have it down to a science, so the large group
- has largely left them alone. Most of their work is converting things
- to ``normal'' form, which is mostly tabular, and throwing away the
- stuff that is language-dependent. They made good use of their time,
- cranking through a good bit of the .4 draft.
-
- 6. Threads (P1003.4a)
-
- The meeting saw two new proposals. Both suggested fruitful changes to
- the current Pthreads work, but neither was accepted as a new base for
- the current draft.
-
- John Zolnowsky of Sun Microsystems submitted one counter-proposal,
- called ``strands'' because ``threads'' was already taken. It was an
- attempt to limit the scope of the interfaces and keep thread semantics
- closer to process semantics. Thus, it would have done away with
- mutexes and conditions, leaving synchronization to be accomplished
- through .4 binary semaphores, presumably modified to have inter-
-
- June 1990 Standards Update IEEE 1003.4: Real-time Extensions
-
-
- - 3 -
-
- thread, not just inter-process semantics. It also proposed more
- process-like exit semantics and a version of per-thread signaling.
- The consensus on the strands proposal seems to have been that it was
- too minimal.
-
- In contrast, the VP (Virtual Processor) proposal, by Paul Borman of
- Cray Research, proposed significant ``incremental'' functionality in
- the form of a lower-level, virtual-processor interface for use by the
- multi-processing and parallel processing communities. (For those
- familiar with Mach, it is roughly to Pthreads as cthreads is to
- Cthreads.) Features of the VP proposal included:
-
- + fork() and exec() semantics for VPs
-
- + per-VP signal semantics
-
- + locks and events for synchronization
-
- + no ordering or scheduling constraints
-
- The group had several concerns about VP
-
- + Could it support real-time requirements without ordering and
- scheduling constraints?
-
- + Could the Pthreads constraints be implemented on top of a layer
- that didn't support them?
-
- + Would the interfaces be used by applications or by system
- implementors?
-
- + Would an application using both Pthreads and VP interfaces
- encounter analogous problems to those caused by read()s and an
- fread()s on the same file?
-
- + Would standard interfaces for locks and events, implemented in
- hardware on many systems, constrain or encourage hardware
- development?
-
- + Would the standard benefit either the user or vendor community?
-
- + How soon could the proposal be completed and gain enough of the
- MP community's consensus to go to ballot?
-
- Perhaps the deciding factor, though, was that the multi-processing AEP
- group (P1003.16) started meeting officially at Snowbird. [Editor:
- Watch for the snitch report, coming soon.] A majority of our group
- (including me) felt that MP-specific standards should grow from
- requirements identified by .16, not be created on the fly by the
- real-time working group.
-
- June 1990 Standards Update IEEE 1003.4: Real-time Extensions
-
-
- - 4 -
-
- In areas that are still not pinned down, the group made progress
- towards a better-defined cancellation mechanism, towards a ``signals
- compromise'' that improves on one hurriedly forged at the previous
- meeting, and towards more process-like exit semantics. The consensus
- was that we should try to accommodate and specify per-thread signal
- state. Although there are a few strong supporters, a majority did not
- feel that specification of per-thread signals is essential to a
- standard.
-
- Paul Borman of Cray Research will present a proposal on this at the
- next meeting. I'll be interested to see what Paul comes up with.
- With three state elements, (mask, pending signals, and action vector)
- and at least three signal delivery types (one, some, all), I can
- create many implementation models and corresponding application
- architectures. It may prove easy to construct a plausible model, but
- hard to construct one that 40 engineers can agree to live with for a
- long time! I suspect a portable application can assume nothing more
- than ``exactly one signal gets delivered exactly once to exactly one
- handler.'' (Looks an awful lot likes signals to a process, doesn't
- it?)
-
- The biggest progress in the meetings was wide consensus achieved for
- the current threads proposal. The working group resolved many of the
- remaining threads issues, and we let Bill Corwin tell IEEE/ISO that we
- expect to ballot P1003.4a in July, after the next meeting.
-
- 7. OSF and UI Cooperating?
-
- Our editor's recent editorial stirred up a hornet's nest. (It wasn't
- so much what Jeff said as what he implied.) In his follow-up posting,
- he said I'd speak about the joint meetings in more detail. I didn't
- really want to but he twisted my arm, so here goes.
-
- The UI MP Working Group and OSF have been cooperating since the middle
- of last year. I happen to work for a company that belongs to both,
- INTERACTIVE Systems Corporation, and though I haven't been to all of
- the joint meetings, I've attended them off and on since last November
- (which is I think, when they started). Those I have attended focused
- on finding solutions to interface/semantic problems that both OSF and
- UI can endorse and that P1003.4 would probably endorse as well.
- Although these meetings haven't been advertised I've seen at least one
- article about OSF/UI/ATT negotiations that mentioned their cooperation
- in the MP arena. And the meetings have been open. At least one non-
- member has shown up uninvited, and was not asked to leave.
-
- Now, it's no secret that several Pthreads-proposal initiators
- (instigators?) work for OSF sponsors. Since the Pthreads-proposal was
- advanced before OSF adopted Mach, it's hard to say whether OSF
- influenced the P1003.4 work or the other way around. Also, in several
- instances, OSF/UI members have voted personal opinions contrary to the
- OSF/UI consensus established at the joint meetings.
-
- June 1990 Standards Update IEEE 1003.4: Real-time Extensions
-
-
- - 5 -
-
- What's the point? The joint meetings contribute to the quality of the
- ..4a work, but they don't drive it. I think the work in P1003.4 is
- pushing vendors to find multi-threading solutions faster than they
- would have on their own. It's an example of POSIX pushing emerging
- technologies, not just creating standards. There's even a chance that
- ..4a will create a standard multi-threading interface before millions
- of installed, heterogeneous systems force the standard to a lowest
- common denominator or to incorporate a particular implementation's
- garbage.
-
- And POSIX is playing another role -- uniting the industry. I
- believe Sun's tooth-and-nail fights with AT&T in P1003.1 led to their
- current cooperation. Maybe the collaboration of OSF and UI on threads
- will also bring more unity to the industry.
-
- 8. The relationship between .4 and .4a
-
- Despite what some think, the threads small group has never had any
- official status. Interest and participation in the threads effort
- goes far beyond the small group, or even the .4 working group into
- other POSIX committees. Some history may clear this up.
-
- Lightweight processes (i.e., threads) have been on P1003.4's list of
- potential work items since its formation. About 3 years ago, the
- working group voted not to pursue them because they were not clearly
- needed and the technology was not sufficiently mature.
-
- About a year and a half ago, threads resurfaced as an item of interest
- to the real-time users, and also to Ada, Transaction Processing, and
- RPC working groups. A small band of ``experts'' went off to draft a
- proposal. Since P1003.4 was an active system-interfaces committee and
- the real-time user community wanted a threads proposal, a lot of hard
- work culminated last summer in Minneapolis in a threads proposal being
- accepted as an additional chapter for the .4 draft.
-
- There are 12 other interface proposals in the .4 draft. Some have
- been mature for nearly two years, (some with broad consensus, others
- without), others are still relatively wet behind the ears. Still, all
- the interfaces are relatively complete (sometimes too complete?), and
- in November, when it seemed appropriate to send .4 to ballot, At the
- Milpitas meeting, the P1003.4 working group decided to include the
- threads chapter in the ballot for comment only, and sought and
- obtained authorization to turn the threads work into a separate work
- item for the P1003.4 working group.
-
- After the Pthreads proposal was accepted into .4, the small group of
- people whose primary interest was threads spent all their time on
- threads. Meanwhile many other .4 members time-shared all the other .4
-
- June 1990 Standards Update IEEE 1003.4: Real-time Extensions
-
-
- - 6 -
-
- activities. Because the Pthreads supporters were so focused, they
- sometimes seemed like a separate group. (Some in the small group
- might have been surprised to learn they weren't. It takes a while to
- understand the POSIX bureaucracy.) Nevertheless, though they may not
- always have appeared to represent the entire working group, the
- Pthreads proposal now enjoys wide consensus. Apparently, the small
- group has listened well to the interests of the working group and the
- POSIX community.
-
- At Snowbird, there wasn't a threads small group, there were seven of
- them! These small groups examined how the current and the alternative
- proposals addressed:
-
- + thread management
-
- + synchronization
-
- + signals/asynch events
-
- + cancellation
-
- + thread-specific data
-
- + re-entrant functions
-
- + process control
-
- After reviewing all the issues, we discovered a consensus in most of
- these areas, and fairly strong agreement on most issues in the three
- or four groups that are still needed. It looks like things are pretty
- well on target.
-
- I'm partially responsible for pushing .4a in before .4 was done, so
- I'm partially responsible for the process's not always appearing fair
- or well organized. I'll take my share of the blame. But I'll also
- take my share of the credit for progress in a technology that I
- believe to be important for real-time and for the entire POSIX
- community.
-
- June 1990 Standards Update IEEE 1003.4: Real-time Extensions
-
- Volume-Number: Volume 20, Number 33
-
- shar.1003.4.033.8174
- echo 1003.5
- cat >1003.5 <<'shar.1003.5.8174'
- From uucp@tic.com Fri Jun 22 20:43:01 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA17291; Fri, 22 Jun 90 20:43:01 -0400
- Posted-Date: 22 Jun 90 19:22:41 GMT
- Received: by cs.utexas.edu (5.64/1.63)
- id AA22512; Fri, 22 Jun 90 19:42:51 -0500
- Received: by longway.tic.com (4.22/tic.1.2)
- id AA22387; Fri, 22 Jun 90 16:48:19 cdt
- From: <jsh@usenix.org>
- Newsgroups: comp.std.unix
- Subject: Standards Update, IEEE 1003.5: Ada bindings
- Message-Id: <379@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: std-unix@uunet.uu.net
- Date: 22 Jun 90 19:22:41 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
-
- An Update on UNIX*-Related Standards Activities
-
- June 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- IEEE 1003.5: Ada bindings
-
- Jayne Baker <cgb@d74sun.mitre.org> reports on the April 23-27 meeting
- in Salt Lake City, UT:
-
- Overview
-
- The Utah meeting was the group's first since our October meeting in
- Brussels. In the interim, we had completed a mock ballot of Draft
- 4.0. Jim Lonjers of Unisys, one of our two co-chairs, managed the
- effort. The document was mailed out to reviewers on December 1, 1989
- and comments were due January 19, 1990. Although only 16% of the
- ballots were returned, the high quality of the comments received made
- the mock ballot a success. Ted Baker, of Florida State University,
- hosted a special meeting in Tallahassee, March 19 - 23, to resolve
- issues and comments; the result was draft 4.1. We did not attend the
- January, New Orleans meeting because balloters lacked sufficient time
- to review and return comments prior to the meeting, though some
- members came to attend other groups' meetings.
-
- Our main goal in Utah was to prepare the Ada Language Binding Document
- for IEEE and ISO Ballot. We addressed the few, unresolved technical
- issues from mock ballot; read draft 4.1 cover-to-cover, for accuracy
- (of text and Ada code), content, and consistency; established a plan
- for addressing the ISO formatting issues; adopted an optimistic
- schedule for IEEE and ISO ballots; and tried to establish a position
- on threads.
-
- Unresolved Technical Issues from Mock Ballot
-
- Most unresolved technical issues from the mock ballot were trivial,
- and quickly resolved. They included the details of iterations (e.g.,
- through a directory), string lower bounds with respect to a string
- returned by a function, the behavior of a file that is opened non-
- blocking when the I/O operation cannot complete, static initialization
- versus ``easy implementation'' of constants, and Text I/O page
- terminators.
-
- __________
-
- * UNIX is a registered trademark of AT&T in the U.S. and other
- countries.
-
- June 1990 Standards Update IEEE 1003.5: Ada bindings
-
-
- - 2 -
-
- The most detailed discussion involved whether or not files should be
- closed on an Exec. The Ada binding provides a Start_Process function,
- which is a primitive that safely creates a new process. In the face
- of Ada tasking, Fork and Exec are unsafe and cannot be used to
- accomplish the results of a Start_Process call. Once one of these
- unsafe primitives is issued, an application program is no longer under
- the control of the Ada run time system; the operating system is
- involved. Therefore, the integrity of the child process is
- jeopardized, and the state of the process's I/O (i.e., which files are
- open/closed) is not guaranteed. Application programs that must be
- safe with Ada tasking and must have files closed and buffers flushed,
- should call Start_Process to create a new process.
-
- Global Issues Effecting the Document
-
- We solved several global, editorial issues. We agreed to use a terse
- wording style except where a more lengthy, explanatory style is needed
- for clarity. We accepted the current packaging of the Ada code
- (multiple packages) and the non-Ada-Language-Reference-Manual coding
- style. Chapter authors were assigned action items to complete their
- respective references and rationale sections.
-
- We spent a large portion of the meeting going through the document,
- chapter-by-chapter, noting very specific changes. Changes recorded in
- a ``master red-lined'' copy were forwarded to appropriate chapter
- authors at the close of the meeting. These changes will be made
- before the June delivery of the document to WG 15.
-
- ISO Format Issues
-
- We need to make several minor modifications, additions, and deletions
- before the June WG 15 meeting, to put the document in ISO standard
- format. After the March, Tallahassee meeting, Jim Moore, of IBM,
- investigated the possibility of hiring a consulting technical editor
- to do this work. IBM volunteered to fund this effort at a level
- sufficient to translate the document into ISO format, maintain that
- format, and make one major edit and two to three minor editorial
- revisions. We accepted IBM's offer, and hired Hal Jespersen.
-
- Threads Issues
-
- As in New Orleans, several group members met with P1003.4 for threads
- discussions. Most group members feel we should establish a position
- on threads, but we remain firmly divided on what it should be.
- Several members believe the currently defined primitives (i.e., the
- most basic system functions) are insufficient, and think that any
- thread model and primitives proposed should be sufficient to support
- Ada tasking, and implement an Ada Run-Time. In contrast, at least one
- group member believes we are unrealistic to require a threads proposal
- in C to meet Ada requirements -- we should, instead, require that C
- and Ada be able to play together in some reasonable fashion, and have
-
- June 1990 Standards Update IEEE 1003.5: Ada bindings
-
-
- - 3 -
-
- a fair understanding of how it will be accomplished. We decided to
- admit our dissension to P1003.4. Interested P1003.5 members are
- acting as liaisons to represent their own views, but these liaisons do
- not represent any consolidated P1003.5. view.
-
- The IEEE and ISO ballots
-
- Steve Deller, our chair, asked the Sponsor's Executive Committee (SEC)
- to approve our entry into the IEEE ballot process. Jim Isaak, SEC
- Chair, met with us early in the week to discuss the IEEE and ISO
- ballot processes and help us establish a schedule to reach IEEE and
- ISO ballots simultaneously. Since the ballot process seems to be of
- general interest, here is a brief overview.
-
- A hierarchy of organizations is responsible for producing
- international operating-system standards and managing the ISO ballot
- process. Two independent, international standards organizations, the
- International Standards Organization (ISO) and the International
- Electrotechnical Committee (IEC), sit on top. Joint Technical
- Committee 1 (JTC 1), a combined effort of these two organizations
- designed to coordinate their efforts in areas of overlap, is at the
- second level; Subcommittee 22 (SC 22), Languages, at the third; and
- Working Group 15 (WG 15), Portable Operating Systems for Computer
- Environments, at the fourth. National organizations, such as the
- American National Standards Institute (ANSI), manage ISO balloting
- within each country. Each participating country has one or more
- representatives in WG 15. The United States has a Technical Advisory
- Group (TAG), which meets with and advises the United States' WG 15
- representatives on the US's position on important issues.
-
- This bureaucracy requires quite a bit of coordination and planning to
- coordinate IEEE and ISO ballots. Most documents require about one
- year to complete the IEEE ballot cycle. Historically, POSIX documents
- have begun with the IEEE ballot process; three to four months later,
- either the original draft, or a newer version incorporating IEEE
- -ballot-process comments, enters the ISO process, and is delivered to
- both WG 15 and SC 22 for approval. Typically, the IEEE ballot is held
- open until all comments from both IEEE and ISO processes are received,
- reviewed, and incorporated. The result is returned to both the IEEE
- and ISO ballot groups for their approval. If the IEEE comments are
- substantive, they enter into the ISO process by the submission of a
- United States position. For example, P1003.1a is the U.S. position on
- P1003.1..
-
- Our group also initiated formation of a formal ballot group -- is the
- group that will actually vote on the current draft. We will deliver
- Draft 5.0, in ISO format, to WG 15 at the Ada Europe meeting this
- June. Draft 6.0 will go to IEEE ballot on August 6. If we receive
- the required 75% response by September 21, the ballot will close
- immediately; if not, we must reconsider the ballot group membership,
- and revise our schedule. In early October, draft 6.0 will be delivered
-
- June 1990 Standards Update IEEE 1003.5: Ada bindings
-
-
- - 4 -
-
- to SC22. At the October meeting, in Seattle, we will resolve the IEEE
- ballot comments and produce Draft 7.0, which will enter the ISO Ballot
- process. At the January '91, New Orleans Meeting, we will determine
- whether a second IEEE Ballot is needed. Any changes to Draft 7.0
- resulting from a second IEEE Ballot will be entered into the ISO
- process through a pro forma objection. There are no guarantees, but
- P1003.5 could reach Draft International Standard (DIS) status by late
- second quarter of 1991.
-
- Conclusion
-
- The April '90/Salt Lake City Meeting was a success. We addressed the
- issues we hoped to address and attained our goal for the meeting. We
- also established a schedule for reaching IEEE and ISO ballot; although
- this schedule is optimistic, we think we can meet it.
-
- June 1990 Standards Update IEEE 1003.5: Ada bindings
-
-
- Volume-Number: Volume 20, Number 38
-
- shar.1003.5.8174
- echo 1003.6
- cat >1003.6 <<'shar.1003.6.8174'
- From uucp@tic.com Thu Jun 28 16:59:49 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA28596; Thu, 28 Jun 90 16:59:49 -0400
- Posted-Date: 28 Jun 90 18:20:43 GMT
- Received: by cs.utexas.edu (5.64/1.65)
- id AA19186; Thu, 28 Jun 90 15:59:39 -0500
- Received: by longway.tic.com (4.22/tic.1.2)
- id AA06448; Thu, 28 Jun 90 15:04:01 cdt
- From: <jsh@usenix.org>
- Newsgroups: comp.std.unix
- Subject: Standards Update, IEEE 1003.6: Security
- Message-Id: <384@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: std-unix@uunet.uu.net
- Date: 28 Jun 90 18:20:43 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
- An Update on UNIX*-Related Standards Activities
-
- June, 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- IEEE 1003.6: Security
-
- An anonymous source reports on the April 23-27 meeting in Salt Lake
- City, UT:
-
- Apologia
-
- This is my first and last review as a snitch. [ Editor: We thank you
- for doing it, and hope your circumstances change to allow you to file
- more. ] In it, you'll see no party line. My views will sometimes be
- controversial, and I hope they spark discussion and feedback. They
- represent neither the views of my company nor of its clients -- I'm
- submitting this anonymously so no one can misconstrue them as being my
- company's -- and they're certainly not meant to represent the
- consensus of the 1003.6 Working Group.
-
- I'll put my biases on the table. I'm a commercial user and commercial
- software provider, not a government user, government software
- provider, or UNIX vendor. To some degree, these biases have
- influenced the committee, since I've been active in the group since
- its inception and attended every 1003.6 meeting. With that
- perspective, let's begin.
-
- 1. Overview
-
- The 1003.6 Working Group is putting together a Department-of-Defense-
- inspired version of UNIX. Our efforts will help vendors sell systems
- to the U.S. Government and its contractors. All our interfaces will
- make it easier to evaluate conforming systems at one of the DoD's
- Trusted Computer Security Evaluation Criteria (TCSEC) levels. This is
- not inherently bad, but it does sell the commercial and international
- communities short. (More on this later.)
-
- The working group is considering four areas: Discretionary Access
- Control (DAC), Mandatory Access Control (MAC), Least Privilege, and
- Audit.
-
- __________
-
- * UNIX is a registered trademark of AT&T in the U.S. and other
- countries.
-
- June, 1990 Standards Update IEEE 1003.6: Security
-
-
- - 2 -
-
- 1.1 Discretionary Access Control
-
- The DAC group's job is hard. They are devising an Access Control List
- (ACL) mechanism that must co-exist with the familiar user/group/other
- mechanism. ACLs are discretionary because the user, not the system,
- decides each object's access rights. The traditional user/group/other
- mechanism is also discretionary: file protections are specified by the
- user. ACLs extend this by allowing users to grant different access
- permissions to arbitrary lists of named users and groups. (In other
- words, the traditional mechanism is an ACL with exactly three
- entries.) Designing an ACL is easy; maintaining compatibility with
- chmod, stat, umask, and the file creation mask of creat isn't.
-
- 1.2 Mandatory Access Control
-
- MAC is another type of access control mechanism. All system objects
- get a security label and all system users have a security
- classification set by the system or the Security Administrator
- (Systems Administrator). Users have no control over this mechanism's
- application; objects created by a user of classification X
- automatically receive a security label of X. Only users with
- appropriate classifications can access or modify a system object. (As
- a useful, if inexact, analogy, think of the way UNIX automatically
- assigns file ownerships.)
-
- The TCSEC security criteria's popularity and widespread acceptance
- have given MAC another connotation -- that of a codification of the
- familiar, U.S.-government, hierarchical security classifications: Top
- Secret, Classified, and Unclassified. Government policy prohibits
- users of a lower classification from viewing work of a higher
- classification. Conversely, users at a high classification may not
- make their work available to users at a lower classification: one can
- neither ``read up'' nor ``write down.'' There are also compartments
- within each classification level, such as NATO, nuclear, DOE, or
- project X. Access requires the proper level and authorization for all
- compartments associated with the resource. The MAC group is defining
- interfaces for such a mandatory mechanism. It's not as confusing as
- it sounds, but outside of the DoD it is as useless as it sounds.
- (Prove me wrong. Show me how this DoD policy is useful in a
- commercial environment.)
-
- 1.3 Least Privilege
-
- The Least Privilege group is eliminating root. They're creating both
- a list of privileges to encompass all of root's special uses, (e.g.,
- set-uid to a different user-id, create a directory, create a file
- system, override DAC protection) and a mechanism to inherit, assign,
- and enable those privileges.
-
- June, 1990 Standards Update IEEE 1003.6: Security
-
-
- - 3 -
-
- 1.4 Audit
-
- The Audit group is preparing a standard interface for a logging
- mechanism, a standard format for logging records, and a list of system
- calls and commands to log.
-
- 2. Standards
-
- At the ISO level, there will be no separate security standard. Our
- work will be merged with the 1003.1 (System Interface), 1003.2
- (Commands and Utilities), and 1003.7 (System Administration) work in
- the ISO 9945-1, -2, and -3 standards. This means every conforming
- system will include security mechanisms. I like this. Do you?
-
- 3. Scope and motivation
-
- All 1003.6 members feel we are making POSIX secure, not merely helping
- sell systems to the U.S. government. Our work is important and
- necessary (except, of course, MAC), but I think our focus has been too
- narrow. We included mechanisms for the TCSEC criteria but stopped
- there. We haven't sought out the work of other countries. We haven't
- considered the work being done in international standards bodies such
- as ISO and CCITT. We haven't explicitly considered commercial users.
- We've limited ourselves to helping provide TCSEC-conforming systems.
- Many of us believe that the TCSEC criteria are good for commercial
- applications. Is that hopeful claim just self-serving? We don't
- know. I wish eminent computer scientists and researchers had gotten
- together to study the needs of commercial users and drawn up an
- independent set of commercial security requirements. But they didn't.
-
- Kevin Murphy, of British Telecom, is the ISO/IEC JTC1/SC22/WG15
- security rapporteur -- he formally represents the international
- community's concerns and views. In January, Kevin brought several of
- these to the working group's attention, including our TCSEC biases and
- lack of attention to ISO activities. The international set seems to
- consider the document's constant references to the TCSEC work
- provincial and inconsiderate of other countries' requirements. They
- also feel we should be more aware and accepting of ISO terminology in
- the document. Kevin also says our scope is too limited in the CCITT
- X.400 and X.500 areas.
-
- 4. Snowbird
-
- June, 1990 Standards Update IEEE 1003.6: Security
-
-
- - 4 -
-
- 4.1 Plenary
-
- The meeting opened with a short plenary session. This time, the first
- topic of discussion was the progress of the 1003.6 draft document.
- Mike Ressler, of Bellcore, accepted the position of technical editor
- and brought a new draft of 1003.6, which contained work of all but the
- Audit subgroup. In addition, an electronic copy of the document was
- available for the subgroups to modify and update during the meeting.
- The technical editor position had been open since October. No draft
- was available during this time, which worried us since it prevented us
- from setting any realistic completion date. With a draft in hand and
- a technical editor we now project completion in April, 1991.
-
- Charlie Testa's absence meant we lacked our usual, detailed report on
- TRUSIX. (TRUSIX is a DoD-sponsored organization made up of the
- National Computer Security Center, AT&T, and several other companies.)
- Rick Sibenaler and Shaun Rovansek, of the NCSC, gave us a brief
- update, reporting that the audit rationale will be available at the
- July POSIX meeting and that select experts are now reviewing the draft
- version of their formal model, which is written in a formal
- verification language, INA JO.
-
- Some of the work of TRUSIX augments the work of 1003.6 -- pursuit of
- a formal security model and descriptive, top-level specification, and
- a mapping between them, for example -- but some overlaps. I'm still
- puzzled over why TRUSIX has pursued audit and DAC mechanisms when
- 1003.6 is doing the same work. (Another challenge: can anyone out
- there tell me?) To their credit, TRUSIX is accomplishing their goals
- much faster than 1003.6. For example, Charlie reported in January
- that the TRUSIX DAC work is already complete. This speed may be at
- the expense of POSIX, since many very good people in both
- organizations are forced to split time between the two unnecessarily.
-
- Mike Ressler reported on the networking/administration/security
- liaison group, which spends an afternoon at every POSIX meeting
- discussing mutual concerns of these three independent working groups.
- Here are the liaison group's goals, in areas of our common interest:
-
- + identify areas of overlapping or missing coverage,
-
- + provide an interface to ISO, ECMA, CCITT, and other international
- bodies, and
-
- + exchange ideas and discuss related issues.
-
- Peter Cordsen, of DataCentralen (Denmark), presented Danish security
- requirements. They define three levels of sensitivity, with criminal
- data among the most sensitive. There was no specific comparison to
- either the U.S. TCSEC or the emerging European security criteria.
- Peter suggested that the security working group begin addressing
- authentication, a position that received much support from other
- representatives.
-
- June, 1990 Standards Update IEEE 1003.6: Security
-
-
- - 5 -
-
- 4.2 Draft work
-
- After the plenary, we worked on the document in subgroups.
-
- 4.2.1 Discretionary_Access_Control_(DAC) The group put together a
- new outline for the general and introductory sections of the draft and
- rewrote those sections to follow the new outline. They also resolved
- several issues:
-
- + There will be only one type of default ACL, not the previously
- planned separate types for regular files and directories.
-
- + A mask entry type has been added to provide a mechanism that
- temporarily overrides all other entries without actually changing
- their values or deleting them from the ACL. The feature also
- fits nicely with the current plan for ACL interaction with the
- old POSIX permission bits.
-
- + The user model for both default and actual ACLs will be the same.
- (The internal representations are undefined.) System interfaces
- will be the same, too. A flag will be added to any interfaces
- that need to be able to distinguish the two.
-
- 4.3 Audit
-
- Olin Sibert, of Sun, presented a new, ``compromise'' audit proposal,
- based on an earlier one by Kevin Brady, of AT&T, and Doug Steves, of
- IBM, which he thought resolved some of the earlier work's problems.
- The working group accepted Olin's proposal with minor changes and
- incorporated it into Draft 6, which was distributed in the IEEE May
- mailing.
-
- 4.4 Mandatory Access Control (MAC)
-
- Since Kevin Brady, the MAC chair, was participating in the Audit
- discussion, and Chris Hughes, of ICL, the acting chair, was also
- absent, Joe Bulger, of NCSC, ran the meeting. It is still unclear who
- will chair the MAC subgroup.
-
- Through the joint efforts of Bellcore and AT&T, the MAC draft had been
- translated from a proprietary, word-processor format into the
- [n|t]roff + POSIX-macro format required for inclusion in the draft
- standard. The MAC draft's contents had been stable for several
- meetings, so the group spent the entire week changing the document.
-
- This group seems to be having the most difficulty getting its job
- done. There doesn't seem to be as much discussion and active
- participation in the MAC group as the others.
-
- June, 1990 Standards Update IEEE 1003.6: Security
-
-
- - 6 -
-
- 4.5 Privileges
-
- No functional changes were made to the privileges material at this
- meeting, but significant changes were made to the rationale. The
- group also firmed up concepts and disambiguated functional
- ambiguities.
-
- 4.6 Networking, Administration, and Security Liaison
-
- The networking/administration/security liaison group held its second
- meeting Wednesday afternoon. The meeting, chaired by Mike Ressler,
- started by reviewing the group's scope and goals.
-
- Since there had been no ISO meeting since the January POSIX meeting,
- Yvon Klein, of Group Bull (France), didn't have anything new to say
- about ISO's security activities.
-
- As part of the group's continuing efforts to and identify problem
- areas, the system administration group and two networking groups gave
- presentations on their work. Steve Carter, of Bellcore, presented the
- scope and charter of the system administration group, 1003.7, and
- explained their use of an object-oriented paradigm. Jim Oldroyd, of
- the Instruction Set, followed this by presenting the work of 1003.7's
- interoperability subgroup.
-
- Kester Fong, of General Motors, gave an overview of the FTAM group.
- He left us with the impression that there wasn't much room for
- collaboration, but we'll surely need to review the relationship
- between the file-system's security semantics and those of FTAM.
-
- Jason Zions, of HP, gave one of the most interesting and aggressive
- presentations of the day, on the work of the Transparent File Access
- Group, which included a preliminary list of issues that 1003.8 feels
- need to be reviewed.
-
- Finally, David Rogers, of ICL (Britain), gave a presentation on the
- European security criteria. He predicted harmonization by June, 1990
- of the work of Britain, France, Germany, and Holland. The European
- criteria will define separate levels of functionality and assurance.
- There will be ten classes of functionality. The first five are
- hierarchical and are similar to the U.S. Orange-Book criteria; the
- remaining five address particular security needs, such as integrity,
- availability, and networks. There are seven classes of assurance. A
- product evaluated under these criteria is likely to receive a rating
- from the first five functional classes, one or more of the next five
- functional classes, and an assurance rating.
-
- June, 1990 Standards Update IEEE 1003.6: Security
-
-
- - 7 -
-
- 4.7 Final Comments
-
- With the short plenary session, the availability of the draft document
- in electronic form, and the presence of many lap-top systems to work
- on, this meeting was one of our most productive. The group seems to
- have picked up enthusiasm from the knowledge that our work is coming
- together and the end is in sight.
-
- June, 1990 Standards Update IEEE 1003.6: Security
-
- Volume-Number: Volume 20, Number 55
-
- shar.1003.6.8174
- echo 1003.7
- cat >1003.7 <<'shar.1003.7.8174'
- From jsq@longway.tic.com Sun Jun 3 17:25:51 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA29512; Sun, 3 Jun 90 17:25:51 -0400
- Posted-Date: 3 Jun 90 21:21:41 GMT
- Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
- id AA09943; Sun, 3 Jun 90 16:25:48 -0500
- Received: by longway.tic.com (4.22/4.16)
- id AA20945; Sun, 3 Jun 90 16:22:16 cdt
- From: <usenix.org!jsh@longway.tic.com>
- Newsgroups: comp.std.unix
- Subject: Standards Update, IEEE 1003.7: System Administration, Interoperability Subgroup
- Message-Id: <713@longway.TIC.COM>
- Sender: std-unix@longway.tic.com
- Reply-To: std-unix@uunet.uu.net
- Date: 3 Jun 90 21:21:41 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
- An Update on UNIX<=-Related Standards Activities
-
- May 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- IEEE 1003.7: System Administration, Interoperability Subgroup
-
- Jim R. Oldroyd <jr@inset.com> reports on the April 23-27 meeting in
- Salt Lake City, UT:
-
- POSIX has given P1003.7 a charter to define both command-line and
- applications-programming interfaces for administering multiple,
- networked machines from a central point. Most reports on this group
- seem to focus on the group's object-oriented approach: the
- administerable classes the group is defining, their attributes
- (properties) and their operators. [Editor: Martin Kirk has promised
- us a report on this. Watch for it soon.]
-
- Sometimes overlooked in this object-oriented frenzy is another,
- equally important, and perhaps more difficult goal of the group:
- interoperability.
-
- Imagine, for example, an administrator who wishes to execute an
- operation on some fraction of nodes in a large, heterogeneous network
- of POSIX systems. The administrator wants to be able to issue the
- request once -- and at his or her own terminal. The system should
- take care of determining which actual objects are affected and of
- communicating the request to them.
-
- How should this be done? The fact that today's networks are
- heterogeneous means that it is not sufficient for vendors simply to
- supply systems with a consistent set of administerable object classes.
- Nor is it enough for vendors to define a consistent set of commands
- and API names that operate on these classes. On top of this, there
- has to be a consistent language for systems from different vendors to
- communicate with each other in order to tell each other that changes
- have to be made to some of the objects they are supporting.
-
- The P1003.7 Interoperability subgroup is defining a standard protocol
- for communication with remote objects.
-
- Currently, we are trying to work out the protocol's requirements. The
- protocol will have to support varied system-management philosophies.
-
- __________
-
- => UNIX is a registered trademark of AT&T in the U.S. and other
- countries.
-
- May 1990 IEEEd1003.7:dSystem Administration, Interoperability Subgroup
-
-
- - 2 -
-
- Some operations, such as re-enabling all PostScript<= printers, should
- be queued and executed independently for each target. Failure to
- enable one printer does not mean that the other printers should remain
- disabled. Others operations must be atomic over the domain, for
- example, when adding a user to a set of machines, it is necessary to
- confirm that a UID is available on all target machines before adding
- the user to any machine.
-
- Each of these problems saddles the protocol with a different
- requirement. The former case could be handled by broadcasting an
- instruction and collecting success or failure reports later; the
- latter requires a two-phase commit, requesting confirmation that
- successful completion is possible throughout the domain before
- actually mandating the change.
-
- Do we have to invent a new protocol from scratch? P1003.7 is actively
- studying existing protocols, such as ISO's CMIP/CMIS and the Internet
- SNMP. Both of these are existing protocols designed to manage objects
- across multiple systems -- exactly as per P1003.7's needs. However,
- both of these are actually designed to manage the network itself, and
- it is not clear that they lend themselves to management of things like
- users, printers and filesystems (etc.) properly. We hope to discover
- whether some existing protocol will fill the bill in the next few
- meetings.
-
- The Interoperability subgroup of P1003.7 will continue work in this
- area at our next meeting (Danvers, MA, July 16-20). If you are an
- interested party, we want to hear from you.
-
- __________
-
- => PostScript is a trademark of Adobe Systems, Inc.
-
- May 1990 IEEEd1003.7:dSystem Administration, Interoperability Subgroup
-
- Volume-Number: Volume 20, Number 22
-
- shar.1003.7.8174
- echo 1003.9
- cat >1003.9 <<'shar.1003.9.8174'
- From uucp@tic.com Sat Jun 23 14:45:48 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA19419; Sat, 23 Jun 90 14:45:48 -0400
- Posted-Date: 23 Jun 90 12:21:21 GMT
- Received: by cs.utexas.edu (5.64/1.63)
- id AA17434; Sat, 23 Jun 90 10:02:01 -0500
- Received: by longway.tic.com (4.22/tic.1.2)
- id AA24904; Sat, 23 Jun 90 09:25:02 cdt
- From: <jsh@usenix.org>
- Newsgroups: comp.std.unix
- Subject: Standards Update, IEEE 1003.9: FORTRAN bindings
- Message-Id: <380@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: std-unix@uunet.uu.net
- Date: 23 Jun 90 12:21:21 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
-
- An Update on UNIX*-Related Standards Activities
-
- May 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- IEEE 1003.9: FORTRAN bindings
-
- Michael Hannah <mjhanna@SANDIA.GOV> reports on the April 23-27 meeting
- in Salt Lake City, UT:
-
- FORTRAN bindings committee prepares to go to ballot
-
- The FORTRAN bindings committee is preparing the official call for a
- ballot group. Because the POSIX work is all done under the auspices
- of the IEEE Technical Committee on Operating Systems Standards
- Subcommittee (TCOS-SS), all members of the ballot group must be both
- regular IEEE or Computer Society members. and members of the TCOS-SS
- (no extra charge to join). Non-members may submit informative
- ballots, but such ballots cannot count towards the required response
- percentage (75%), or percentage of affirmative responses (also 75%)
- required for passage of the standard. [Editor: Institutional
- Representatives are exceptions to this rule. See IEEE 1003.1-1988,
- p. 177 for a detailed explanation of the rules.]
-
- For more information, the appropriate membership forms, and
- instructions for returning the forms to the proper IEEE offices,
- contact the committee chair, John McGrory, at the address listed at
- the end of this article. This information/sign-up packet will be
- available by the end of June, but you may contact the chair as soon as
- you want your name added to the distribution list.
-
- The formal sign-up period is expected to be August 15 through October
- 19, 1990. The ballot period is expected to last from November 9, 1990
- through January 4, 1991. We are especially eager to attract a large,
- representative balloting group, and encourage interested individuals
- to sign up. While the views represented on the P1003.9 working group
- have been appropriate and varied, the number of active members has
- been small (typically, around a dozen).
-
- __________
-
- * UNIX is a registered trademark of AT&T in the U.S. and other
- countries.
-
- May 1990 Standards Update IEEE 1003.9: FORTRAN bindings
-
-
- - 2 -
-
- Some history
-
- As the committee prepares to go to ballot, it might be of value to
- review some of the more sticky issues that the working group has
- addressed. The formal, adopted charter of the committee is to provide
- access to the POSIX-defined, standard operating system interface and
- environment, directly from the FORTRAN language. There are two major
- issues of scope that bear comment: ``Access to how much of POSIX?''
- and ``Which FORTRAN?''
-
- Some POSIX features are easily imagined as useful to a FORTRAN
- application (e.g., chmod, exec, etc.); some are less easily imagined
- (pick your favorite obscure system call). It was unclear where to
- draw the line, so the committee took the attitude of ensuring access
- to all features defined in 1003.1 (IEEE 1003.1-1988, or ISO/IEC 9945-
- 1:1990). It seemed clear that full functional access would be
- provided by most vendors, so full standardization seemed called for.
- Some diehard C language addicts continue to ask, ``Why have any
- FORTRAN bindings?'' Although most vendors provide a method of calling
- C functions from FORTRAN, they vary from vendor to vendor. Further,
- any library of C routines provided by a vendor to map FORTRAN
- constructs to the POSIX defined procedures is bound to differ among
- vendors. The P1003.9 bindings are silent on implementation, so the
- FORTRAN subprograms defined in the bindings could be implemented as
- just such a library. The bindings just standardize the interface.
- Keeping in mind the POSIX goal of application portability, only a
- truly complete FORTRAN binding would provide portability of any
- FORTRAN application.
-
- A harder issue was, ``Which FORTRAN?'' Our choices were:
-
- 1. FORTRAN 77 [ANSI X3.9-1978, ISO 1539-1980 (E)],
-
- 2. a codification of common extensions/enhancements to FORTRAN 77,
- or
-
- 3. the revised FORTRAN standard emerging from the ANSI X3J3
- committee -- previously referred to as FORTRAN 8X but now
- called Fortran 90. (The working group has been delighted to
- have an officially appointed representative of X3J3 as an active
- member.) [Editor: Note that Fortran 90 will finally let us type
- the name of the language without using the caps-lock key. ``And
- gain is gain, however small.'' -- Robert Browning]
- We chose the first.
-
- For FORTRAN 77 vs. Fortran 90, we were swayed by the fact that FORTRAN
- 77 is currently the only adopted standard. (Fortran 90 is scheduled
- to be adopted as an ANSI standard after P1003.9 goes to ballot.)
- Further, FORTRAN-77-based applications are expected to exist for some
- years. Thus, the working group felt that FORTRAN-77-based bindings
- would be of value to the user community. The working group expects to
-
- May 1990 Standards Update IEEE 1003.9: FORTRAN bindings
-
-
- - 3 -
-
- develop a new set of bindings, based solely on Fortran 90, after
- completion of the FORTRAN 77 bindings (and after the Fortran 90
- standard is adopted). One result of this decision is a subprogram-
- naming scheme that reflects the version of the language (e.g., CALL
- F77MKDIR(...) ). This will ensure that there will be no name-space
- conflict with similar-purpose subprograms in a future Fortran 90
- binding.
-
- An even harder issue, once we decided to base the bindings on FORTRAN
- 77, was whether to define the bindings as extensions and/or
- enhancements to the language itself, or simply as a library of
- callable FORTRAN subprograms. While the latter was finally chosen,
- there was considerable argument for the former. In fact, one
- extension to FORTRAN 77 was considered minimally essential. The
- current document requires the language to differentiate external names
- unique to 31 characters, even though the FORTRAN 77 standard limits
- them to six. The extension seems harmless. Fortran 90 specifies
- uniqueness to 31 characters and all current FORTRAN 77 compilers
- researched provide this extension. Further, since the list of P1003.9
- subprogram names is finite, if necessary, a vendor could provide a
- preprocessor to convert these names into unique strings of six
- characters.
-
- If the P1003.9 bindings had defined changes to the language itself,
- then major missing constructs in the FORTRAN 77 language needed for
- easy POSIX access (most notably, structures and pointers) could have
- been provided by choosing either the emerging Fortran 90 constructs or
- an existing vendor solution. At first the working group felt that
- this might be required for some access features. However, as we
- struggled with each issue, working papers and proposals were
- introduced that resolved every one with callable FORTRAN subprograms
- (though some might argue about elegance or ease of use). While we
- mostly steered clear of ``ease-of-implementation'' arguments, since we
- viewed the FORTRAN 77 bindings as an interim, we felt that vendors
- would be quicker to implement a library of subprograms than
- modifications to compilers.
-
- A final, hard question of standard scope concerned whether to restrict
- the standard to 1003.1, or expand it to general, FORTRAN-application
- portability issues, both within and outside the POSIX arena. Both a
- lack of resources and a desire to provide a timely bindings on the
- heels of 1003.1 made us decide to limit the scope to 1003.1
- functionality.
-
- As other base standards are produced (e.g., 1003.2, 1003.4, etc.), we
- expect to construct and ballot bindings for those standards. For
- example, we have worked with P1003.2 in defining a standardized
- command to invoke the FORTRAN compiler (after a number of iterations,
- now named fort77) which is part of their current draft. Actual
- P1003.9 bindings to 1003.2 might include definitions of additional
- utilities of use to FORTRAN applications not mentioned in the base
- 1003.2 standard (e.g., f77split, f77lint, etc.).
-
- May 1990 Standards Update IEEE 1003.9: FORTRAN bindings
-
-
- - 4 -
-
- Another argument against adding features was that many, if not most,
- of the problems we saw in portability are solved by new constructs in
- Fortran 90. Many of us felt that as a standards group we should only
- provide a minimum set of features for ``perhaps-soon-to-be-obsolete''
- FORTRAN 77, and thereby speed up the date for providing full bindings
- to the new Fortran 90, which provides more features for application
- portability.
-
- How to get involved
-
- If you have strong feelings about these issues, the most effective
- avenue to express them at this point is to join the balloting group
- being formed. Nevertheless, if you wish to discuss them before this
- you can also directly contact the chair (John McGrory) or me (vice-
- chair, Michael Hannah), or join the e-mail discussion group.
- Addresses follow:
-
- P1003.9 Chair
- John McGrory
- Hewlett Packard Co.
- Division 2615
- 19046 Pruneridge Avenue
- Cupertino, Ca 95014
- mcgrory%hpda@HPLABS.HP.COM
-
- P1003.9 ViceChair
- Michael Hannah
- Sandia National Labs
- Albuquerque, NM 87185
- mjhanna@SANDIA.GOV
-
- Un-moderated mailing list:
- posix-fortran@SANDIA.GOV
- To join the list, send request to:
- posix-fortran-request@SANDIA.GOV
-
- May 1990 Standards Update IEEE 1003.9: FORTRAN bindings
-
- Volume-Number: Volume 20, Number 43
-
- shar.1003.9.8174
- echo tag
- cat >tag <<'shar.tag.8174'
- From uucp@tic.com Tue Jul 31 14:49:23 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA05992; Tue, 31 Jul 90 14:49:23 -0400
- Posted-Date: 31 Jul 90 16:47:04 GMT
- Received: by cs.utexas.edu (5.64/1.68)
- id AA17561; Tue, 31 Jul 90 13:49:15 -0500
- Received: by longway.tic.com (4.22/tic.1.2)
- id AA20065; Tue, 31 Jul 90 13:50:11 cdt
- From: <jsh@usenix.org>
- Newsgroups: comp.std.unix
- Subject: Standards Update, U.S. TAG to ISO/IEC JTC1 SC22 WG15
- Message-Id: <408@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: std-unix@uunet.uu.net
- Date: 31 Jul 90 16:47:04 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
-
- An Update on UNIX*-Related Standards Activities
-
- July, 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- U.S. TAG to ISO/IEC JTC1 SC22 WG15
-
- Susanne Smith <sws@calvin.wa.com> reports on the June 1 meeting in
- Denver, Colorado:
-
- 1. Overview
-
- Before you ask, ISO/IEC JTC1 SC22 WG15 is ISO POSIX. The U.S. TAG is
- the United States Technical Advisory Group, which formulates the U.S.
- position on WG15 issues and chooses the U.S. delegation to WG15
- meetings.
-
- The TAG usually meets in conjunction with the IEEE POSIX meetings.
- The June 1 meeting was a special meeting, held to complete the many
- unfinished tasks left from Snowbird and ready the instructions to the
- U.S. delegation before the June 11 WG15 meeting.
-
- 2. Two vacant positions
-
- Terry Dowling, vice-chair and security rapporteur, resigned after the
- New Orleans meeting in January. Currently there are no candidates for
- the vice-chair position. Donn Terry has been assuming the
- responsibilities in the interim.
-
- A rapporteur group is a group of technical experts that discusses
- specialized aspects of a particular standards effort. The specialized
- aspects usually have a broader scope than an individual standard and
- require coordination of effort between standards bodies. WG15 has
- three: internationalization, security, and conformance. The TAG
- currently has rapporteurs for internationalization (Donn Terry) and
- conformance (Roger Martin). John Hill and Al Weaver said that they
- would be able to cover the June 11 security meetings in Paris.
-
- __________
-
- * UNIXTM is a Registered Trademark of UNIX System Laboratories in
- the United States and other countries.
-
- July, 1990 Standards Update U.S. TAG to ISO/IEC JTC1 SC22 WG15
-
-
- - 2 -
-
- 3. Some important decisions from Snowbird
-
- 3.1 Profile groups get help
-
- SC22 asked WG15 to develop a plan to help groups writing profiles. (A
- profile is an application-area-specific set of pointers to standards.
- For example, P1003.10 is developing a supercomputing profile.) Wearing
- his WG15-convener hat, Jim Isaak drafted and submitted a ``POSIX
- Harmonization Proposal'' -- a plan that gives profile groups a way to
- observe WG15 meetings and participate when their proposals are being
- considered. The plan lists the responsibilities of both the
- ``harmonization liaison'' and WG15. The TAG approved the plan with
- comments, including changing ``harmonization'' to ``coordination.''
- [Editor: I think ``harmonization'' is ugly, but it does parallel the
- ``MUSIC'' acronym that's gaining ground in the UNIX, er, ``Open
- Systems'' arena.]
-
- 3.2 Speeding international approval
-
- SC22 has asked all working groups doing development work in national
- bodies (for example, WG15 and IEEE P1003) to find a way to synchronize
- their national and international efforts. Such synchronization will
- help eliminate delays between national-body approval and ISO approval;
- it will also insure that both national and international bodies use
- the same text and speed achieving a broad consensus by circulating
- them in both bodies simultaneously.
-
- Donn Terry, TAG chair, and Jim Isaak (him again?) shouldered the
- burden of developing the plan and submitted it at Snowbird. The meat
- of the proposal is the following synchronization process:
-
- - SC22 review and comment
-
- - IEEE balloting; document ready for broad comment
-
- - U.S. recommends CD registration be requested by WG15. (CD,
- Committee Document, is now used instead of DP Draft Proposal.)
-
- - CD comments fed to IEEE balloting; IEEE recommendations fed to CD
- process
-
- - IEEE final approval delayed until updated draft is suitable for
- DIS registration
-
- - DIS and ANSI approval run in parallel; substantive feedback from
- DIS ballot creates an IEEE PAR
-
- Final authority to approve or reject the plan rests with SC22 and the
- IEEE Computer Society Standards Activities Board, but the TAG voted
- ``No with binding comments,'' objecting to a few details. If the
- problems listed below are fixed, the vote will automatically change to
-
- July, 1990 Standards Update U.S. TAG to ISO/IEC JTC1 SC22 WG15
-
-
- - 3 -
-
- ``Yes.''
-
- + Under the plan, TCOS/SEC documents, such as standards drafts and
- administrative status reports, would all be sent to WG15 and SC22
- to encourage feedback before balloting. The plan would force
- TCOS working groups to use the JTC1 format for draft documents.
- Currently POSIX documents use a unique TCOS format, so the TAG
- objected to this requirement but added the comment that the
- format should be one approved by the ITTF (Information Technology
- Task Force, formerly, the ``Central Secretariat'').
-
- + The TAG also objected to the requirement that TCOS meet outside
- of the U.S. mainland every 12 to 18 months to encourage
- international participation. It did not object to meeting
- outside the U.S., but thought the requirement did not belong in
- the plan.
-
- 4. Decisions made in this meeting
-
- 4.1 Formatting nits still block ISO UNIX
-
- The 9945-1 document (the ISO version of 1003.1) still has problems.
- WG15 recommended registering it as an International Standard (IS), but
- is now stuck in a loop: ISO demands a format change, the IEEE makes
- the change, then ISO finds a new formatting problem. The TAG thinks
- this loop has gone on long enough, and recommended that WG15 form an
- ad hoc committee to determine what ISO will accept.
-
- 4.2 P1003.1 updates go international
-
- WG15 is balloting to make 9945-1.2 (which corresponds to 1003.1a,
- draft 5) a Draft International Standard (DIS). The TAG approved the
- U.S. position with comments. What's that mean?
-
- Voting within WG15 is done by member country. To arrive at the U.S.'s
- position on a WG15 ballot, the TAG members draft a position then vote
- on it, one vote per corporation. (POSIX participation, in contrast,
- is by individuals.) The final ballot resolution is presented to WG15
- as the U.S. position, Sometimes a voice vote suffices, but DISs, NPs
- (New Proposal, formerly New Work Item), or CDs (Committee Document,
- formerly Draft Proposal), require a letter ballot.
-
- The initial letter-ballot vote was nine yesses, two noes (with
- comments), three abstentions; the two negative ballots were from Sun
- and AT&T. We considered three options for AT&T's comments:
-
- 1. do nothing and write a response to AT&T explaining why,
-
- 2. pass the comments on to WG15, or
-
- July, 1990 Standards Update U.S. TAG to ISO/IEC JTC1 SC22 WG15
-
-
- - 4 -
-
- 3. pass the comments on to the 1003.1 working group, who could
- better judge their technical merits,
-
- and chose the third. In contrast, we incorporated Sun's comment into
- our position. Though someone suggested that AT&T might not be getting
- fair treatment, Sun's comment (which simply noted that a change made
- in chapter eight was not reflected in chapter two) was only a response
- to the TAG ballot, while the AT&T comments, were more far-reaching
- responses to 9945-1.2 itself and demanded a different forum.
- Nevertheless, the group asked the ad hoc committee reforming TAG
- procedures to reconsider the ballot resolution process.
-
- 4.3 How can you be two places at once (when you're ... )?
-
- In light of the amount of time TAG meetings keep members from
- attending working groups, we decided to meet Sundays before and
- Thursdays and Fridays during the POSIX meetings. This new schedule
- will start with the Seattle meeting in October. The idea is to
- complete as much as possible on Sunday and have Thursday and Friday
- available if necessary. We agreed that the TAG should allocate this
- much time to avoid one-day meetings like this one. The SEC meeting
- schedule may force this to change; several TAG members are TCOS
- officers, committee chairs, or Institutional Representatives, all of
- which are automatically SEC members.
-
- 4.4 Last, least
-
- Both P1237 and X3T5.5 are working on remote procedure calls (RPC).
- X3T5.5 is specifying the data stream encoding and P1237 is working on
- the Application Programming Interface (API). The TAG recommended that
- the API work be brought to the ISO level under the WG15 umbrella.
-
- July, 1990 Standards Update U.S. TAG to ISO/IEC JTC1 SC22 WG15
-
- Volume-Number: Volume 20, Number 151
-
- shar.tag.8174
- echo x3b11.1
- cat >x3b11.1 <<'shar.x3b11.1.8174'
- From jsq@longway.tic.com Sat May 19 15:44:21 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA28141; Sat, 19 May 90 15:44:21 -0400
- Posted-Date: 19 May 90 19:32:16 GMT
- Received: by cs.utexas.edu (5.61/1.62)
- id AA06961; Sat, 19 May 90 14:44:15 -0500
- Received: by longway.tic.com (4.22/4.16)
- id AA11079; Sat, 19 May 90 14:32:52 cdt
- From: <usenix.org!jsh@longway.tic.com>
- Newsgroups: comp.std.unix
- Subject: Standards Update, ANSI X3B11.1: WORM File Systems
- Message-Id: <694@longway.TIC.COM>
- Sender: std-unix@longway.tic.com
- Reply-To: std-unix@uunet.uu.net
- Date: 19 May 90 19:32:16 GMT
- Apparently-To: std-unix-archive@uunet.uu.net
-
- From: <jsh@usenix.org>
-
-
- An Update on UNIX*-Related Standards Activities
-
- May 1990
-
- USENIX Standards Watchdog Committee
-
- Jeffrey S. Haemer, Report Editor
-
- ANSI X3B11.1: WORM File Systems
-
- Andrew Hume <andrew@research.att.com> reports on the April 17-19, 1990
- meeting in Tucson, AZ:
-
- Introduction
-
- X3B11.1 is working on a standard for file interchange on write-once,
- non-sequential (random access) media: a portable file system for
- WORMs. This was our fourth meeting. With many major issues somewhat
- settled, our main, remaining decisions are how to implement directory
- hierarchies and how to manage free space.
-
- Multi-Volume Sets
-
- WORM file systems store a fair amount of information per file (such as
- most of the fields in struct stat), per directory, per partition, and
- per volume. A volume is a logical address space associated with a
- piece of physical media. For example, a WORM disk that can only be
- accessed one side at a time would be two volumes. Each volume has a
- label block describing its size, partitions, directory hierarchies,
- free-space management, and so on. (Free-space management is discussed
- below; for now, this could mean a pointer to the next free block.)
-
- Informally, multi-volume sets means files and directories can be
- spread over several volumes. Here are some requirements for this
- feature:
-
- - A file can be bigger than a volume (file sizes are limited to
- 2**64 bytes).
-
- - You can append to a file.
-
- - You can update any part of a file.
-
- - All volumes need not be simultaneously accessible. (That is, if
- you have a three-volume volume set, you don't need three drives.)
-
- __________
-
- * UNIX is a registered trademark of AT&T in the U.S. and other
- countries.
-
- May 1990 Standards Update ANSI X3B11.1: WORM File Systems
-
-
- - 2 -
-
- - Each volume, and the whole volume set, must be consistent after
- an update.
-
- - Usable, although perhaps not fast, on a single drive. The idea
- is that you can't mandate that the control structures for the
- volume set be distributed over the set, because that would mean
- that on single-drive systems, users might have to mount every
- volume to recover even a single file. We would like to require
- only that the user mount the volume the file is on and perhaps
- one other (the master volume).
-
- - Each volume must be self-contained (for disaster recovery),
-
- - Security control is per volume, directory, and file.
-
- After convincing ourselves that we all spoke roughly the same
- language, we came to consensus decisions for the following questions:
-
- - Can a file description point to extents (files are spread across
- a list of extents) on later volumes? (Yes)
-
- - Can a directory entry point to a file description on a later
- volume? (Yes)
-
- - Must a directory be completely contained on a single volume? (No)
- Why? There's no reason to require it. All implementations are
- likely to use the same primitives to manage files and directories
- (that is, they'll implement directories as files); if you can
- handle multi-volume files correctly, directories should be easy
- too. Some people were concerned about being able to get the
- directory in one (more or less) I/O or block (especially for MS-
- DOS) but that can't happen in general; directories and files are
- likely to be spread all over the volume.
-
- - must all the file descriptions for a single directory hierarchy
- fit on a single volume? (no)
-
- - should each volume of a volume set point to the volume describing
- the root of the main directory hierarchy for that set? (yes)
-
- The above involve subtleties not readily apparent; details available
- on request.
-
- Directory Hierarchies
-
- Much discussion centered on how to implement directory hierarchies --
- at least, after our initial surprise discovery that we are committed
- to support multiple directory hierarchies. This commitment comes from
- the CD-ROM standard, ISO 9660, where the intent was to have an ASCII
- directory tree and one or more national-character-set trees.
-
- May 1990 Standards Update ANSI X3B11.1: WORM File Systems
-
-
- - 3 -
-
- [Editor: CD-ROMs, like WORMs, are on write-only media, but solve
- different problems. Both provide tremendous storage capacity, but
- CD-ROMs appear to the user to be read-only, while WORMs appear to
- provide read and write access. Nevertheless, on WORMs, writing to a
- file means either appending characters to a pre-allocated chunk of
- disk, or rewriting a new version of the file in a new place. Once a
- file, or file version, is discarded, the piece of the physical medium
- it's stored on is forever lost, not released for re-use. CD-ROMs are
- for storing the Encyclopedia Britannica; WORMs are for storing
- backups. ]
-
- Our basic choice is between what I call the scattered directory tree,
- which is much like the standard, UNIX file system, and path tables
- (linearized encodings of the tree structure). ISO 9660 supports both.
- Scattered directories are simpler to deal with and somewhat easier to
- update, but probably slow to access because they require too much
- seeking. Path tables seem faster at first glance (large contiguous
- reads, etc.), but their simplicity and speed seem to evaporate when
- the tables are modified. There is no consensus on which method to
- use. I originally held out for two methods, a flexible one and a
- really fast one, but have come to the conclusion, reinforced by
- conversations with Ken Thompson, that it is better to have one
- flexible method in the standard -- scattered directories -- and
- handle accelerators, such as directory trees cached on magnetic disk,
- as system-dependent structures outside the standard.
-
- Suppose you update a file; doesn't that mean you also have to re-write
- the directory, and, therefore, its parent directory, and, therefore,
- its parent directory, and so on all the way up to the root directory?
- And the volume header? How do you find the root directory, the volume
- header, and so on? This stuff is not yet decided but we envision that
- the file description stuff will have preallocated spare space so that
- a few updates can be done without changing anything outside the file
- description. Once this space is full, the system will have to get
- free space elsewhere, which implies updating some other area
- describing the free space. The volume header is in a fixed location
- (probably 8KB in from the start of media) and will point to any later
- volume headers and other stuff (such as where the root of the various
- directory trees are).
-
- Requirements for the directory hierarchy include space and time
- efficiency, robustness (e.g., to minimize damage from a single I/O
- error), a single, fast structure (unlike ISO 9660's two), and that a
- directory entry for a file must be complete (that is, point to all the
- extents for that file).
-
- May 1990 Standards Update ANSI X3B11.1: WORM File Systems
-
-
- - 4 -
-
- Space Allocation and Management
-
- We must support pre-allocation of space (e.g., ``Reserve 40MB of
- contiguous space for file `xyz'. '') both for speed and to support
- systems like the MacIntosh. Because of the latter, we also need to
- support giving back unused reserved space for later use.
-
- These two requirements appear to force the standard to address
- describing the free space in a volume set, which will also be
- important if the standard is extended to cover R/W optical disks,
- where freed blocks need to be cleared before reuse. The two choices
- appear to be run-length encodings of the free space or bitmap
- techniques. The former can degrade to being quite large, while the
- latter have a fixed, but high, overhead (current media hold up to
- 8.2GB/side!).
-
- Finale
-
- We hope to conduct a letter ballot soon after the October, 1990
- meeting. If we can approve a proposal by January, 1991 then it may be
- an ANSI standard by January, 1992. Our next meeting is in Murray
- Hill, New Jersey, on July 17-19, where we expect to adopt the proposal
- being edited by Howard Kaikow as our working proposal. Anyone
- interested in attending should contact either the chairman, Ed Beshore
- (edb@hpgrla.hp.com), or me (andrew@research.att.com).
-
- While this standard may seem of limited interest, because it deals
- only with WORMs, X3B11.1 expects approval shortly to develop a similar
- standard for R/W optical media. It doesn't take much imagination to
- see that standard being extended to apply to all rewritable, direct-
- access media. (Unlike the CD-ROM standards committee, which ignored
- UNIX, this committee has a significant number of UNIX users, including
- representatives from AT&T Bell Labs, Sun, Hewlett-Packard. That, at
- least, insures filenames won't be required to have a compulsory
- three-character suffix and a version number.) Once we have a working
- paper, anyone who cares about portable, multi-volume, multiple-
- character-set file systems should take a look. [Editor: Pay
- attention. He's giving you fair warning.]
-
- May 1990 Standards Update ANSI X3B11.1: WORM File Systems
-
-
- Volume-Number: Volume 20, Number 4
-
- shar.x3b11.1.8174
- exit
-