home *** CD-ROM | disk | FTP | other *** search
Text File | 1990-10-26 | 162.1 KB | 3,891 lines |
- echo 1003.10.a
- cat >1003.10.a <<'shar.1003.10.a.24121'
- From std-unix-request@uunet.uu.net Thu Sep 6 20:21:15 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA00653; Thu, 6 Sep 90 20:21:15 -0400
- Posted-Date: 7 Sep 90 01:34:25 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: emv@math.lsa.umich.edu (Edward Vielmetti)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.10 and 1003.15: Supercomputing and Batch
- Message-Id: <492@usenix.ORG>
- References: <485@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Organization: University of Michigan Math Dept., Ann Arbor MI.
- X-Submissions: std-unix@uunet.uu.net
- Date: 7 Sep 90 01:34:25 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: emv@math.lsa.umich.edu (Edward Vielmetti)
-
- In article <485@usenix.ORG> jsh@usenix.org (Jeffrey S. Haemer) writes:
- [ Well, actually, an anonymous person wrote it; Jeff edited it. -jsq ]
-
- IEEE 1003.10 and 1003.15: Supercomputing and Batch
-
- Just before the close of the meeting, a representative of POSIX.7
- presented some questions about the current direction of the batch
- effort and its relation to the Palladium print system (the Athena
- print system used at MIT). Many current NQS sites queue print
- requests with NQS, and there has been some interest in defining
- printing features. That function, however, is clearly within
- POSIX.7's scope. It is reasonable for POSIX.7 to question if and how
- Palladium and NQS are compatible.
-
- For the record, there's an Internet Engineering Task Force group doing
- work on defining a Network Printing Protocol. I enclose the charter
- of the group as I find it on nnsc.nsf.net:/ietf/npp-charter.txt.
-
- --Ed
-
- Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
-
- Network Printing Protocol (npp)
-
- Charter_
-
- Chairperson:
- Leo McLaughlin, ljm@twg.com
- Mailing Lists:
- General Discussion: print-wg@pluto.dss.com
- To Subscribe: print-wg-request@pluto.dss.com
- Description of Working Group:
-
- The Network Printing Working Group has the goal of pursuing
- those issues which will facilitate the use of printers in an
- internetworking environment. In pursuit of this goal it is
- expected that we will present one or more printing protocols to
- be considered as standards in the Internet community.
- This working group has a number of specific objectives. To
- provide a draft RFC which will describe the LPR protocol. To
- describe printing specific issues on topics currently under
- discussion within other working groups (e.g., security and
- dynamic host configuration), to present our concerns to those
- working groups, and to examine printing protocols which exist
- or are currently under development and assess their
- applicability to Internet-wide use, suggesting changes if
- necessary.
-
-
- Goals and Milestones:
-
- Done Review and approve the charter, making any changes deemed
- necessary. Review the problems of printing in the
- Internet.
- Apr 1990 Write draft LPR specification.
- May 1990 Discuss and review the draft LPR specification. Discuss
- long-range printing issues in the Internet. Review
- status of Palladium print system at Project Athena.
- May 1990 Submit final LPR specification including changes
- suggested at the May IETF. Discuss document on mailing
- list.
- Jun 1990 Submit LPR specification as an RFC and standard.
- Jul 1990 Write description of the Palladium printing protocol
- (2.0) in RFC format.
- Aug 1990 Discuss and review the draft Palladium RFC.
-
- Volume-Number: Volume 21, Number 86
-
- shar.1003.10.a.24121
- echo 1003.2.a
- cat >1003.2.a <<'shar.1003.2.a.24121'
- From std-unix-request@uunet.uu.net Thu Sep 20 19:19:07 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA05804; Thu, 20 Sep 90 19:19:07 -0400
- Posted-Date: 20 Sep 90 21:40:50 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: gwyn@smoke.brl.mil (Doug Gwyn)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.2: Shell and tools
- Message-Id: <531@usenix.ORG>
- References: <530@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
- X-Submissions: std-unix@uunet.uu.net
- Date: 20 Sep 90 21:40:50 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
-
- In article <530@usenix.ORG> std-unix@uunet.uu.net writes:
- -Submitted-by: jsh@usenix.org (Jeffrey S. Haemer)
- - + lint89: This utility is optional, largely because it is
- - controversial for a number of reasons. Obviously, the very name
- - lint89 is painfully bureaucratic. Furthermore, many feel that
- - ANSI C makes it unnecessary; moreover, any remaining required
- - functionality rightfully belongs as an additional option in the
- - c89 (cc) utility. Some point to existing practice. But what is
- - existing practice when the utility's name is lint89? [Editor: On
- - the other hand, it may prove indispensable in detecting
- - portability problems in lex89- and yacc89-generated code.
- - Parenthetically, Draft 10 calls these lex and yacc, but that must
- - just be a temporary oversight; the utilities obligatorily have
- - ANSI C input and output. (One assumes we'll escape c89tags
- - because ctags can be made to work with both flavors.)]
-
- I really do not understand the reasoning behind not just using the
- names "cc", "lint", "lex", etc. The entire software generation system
- needs to work together as an integrated whole. Now that there is an
- official standard for C, any further standardization involving C should
- be connected to standard C. Since the C standard is in almost all ways
- upward-compatible so that "lint", "lex", etc. can be upgraded to support
- standard C and still act as before when fed "old K&R C", so long as the
- software generation system's C compiler understands lex/yacc/whatever
- output there should be no issue here. From the standards point of view
- there should currently be only one notion of what C is.
-
- - D A Gwyn (sporadically acting X3J11/P1003 liaison)
-
- Volume-Number: Volume 21, Number 121
-
- shar.1003.2.a.24121
- echo 1003.2.b
- cat >1003.2.b <<'shar.1003.2.b.24121'
- From std-unix-request@uunet.uu.net Fri Sep 21 13:19:38 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA15461; Fri, 21 Sep 90 13:19:38 -0400
- Posted-Date: 21 Sep 90 13:47:37 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: willcox@urbana.mcd.mot.com (David A Willcox)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.2: Shell and tools
- Message-Id: <532@usenix.ORG>
- References: <530@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: Motorola Microcomputer Division, Urbana, IL
- X-Submissions: std-unix@uunet.uu.net
- Date: 21 Sep 90 13:47:37 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox)
-
- In article <530@usenix.ORG> jsh@usenix.org (Jeffrey S. Haemer) writes:
-
- >A few utilities remain contentious:
-
- > + nice, renice: These require underlying functionality absent from
- > POSIX.1, although POSIX.4 has setscheduler(), which allows
- > applications to set priority and scheduling algorithms.
-
- A point of clarification: These utilities, as defined in 1003.2a,
- do NOT require any functionality that is not in 1003.1. Both can be
- implemented on a bare-bones 1003.1 system as having no effect on
- execution priority. The following, for example, is a valid
- shell script implementation of nice:
-
- case $1 in
- -n) shift;shift;;
- -* shift;;
- esac
- exec $*
-
- renice is a little more complicated, but not much. (It should just have
- to check for valid arguments.)
-
- So saying that you can't implement this on a 1003.1 system is not only
- a red herring, it simply isn't true.
-
- Providing these utilities allows well-mannered applications to make use
- of the priority manipluation features that are already provided by most
- implementations.
-
- David A. Willcox "Just say 'NO' to universal drug testing"
- Motorola MCD - Urbana UUCP: ...!uiucuxc!udc!willcox
- 1101 E. University Ave. INET: willcox@urbana.mcd.mot.com
- Urbana, IL 61801 FONE: 217-384-8534
-
- Volume-Number: Volume 21, Number 122
-
- shar.1003.2.b.24121
- echo 1003.2.c
- cat >1003.2.c <<'shar.1003.2.c.24121'
- From std-unix-request@uunet.uu.net Fri Sep 21 16:19:55 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA12563; Fri, 21 Sep 90 16:19:55 -0400
- Posted-Date: 21 Sep 90 18:29:24 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: rsalz@bbn.com (Rich Salz)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.2: Shell and tools
- Message-Id: <533@usenix.ORG>
- References: <530@usenix.ORG>
- Sender: jsq@usenix.ORG
- X-Submissions: std-unix@uunet.uu.net
- Date: 21 Sep 90 18:29:24 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: rsalz@bbn.com (Rich Salz)
-
- Reporting on 1003.2 (Shell and tools), in <503@usenix.org> Randall Howard writes:
- >+ patch: This utility differs from many others; its origins are in
- > the public domain rather than in a traditional UNIX variants. As
- > a result, many people feel that patch is worthwhile, but not
- > mature enough to standardize.
- I find this sentence totally amazing.
-
- Patch has been around far longer, and is much more worthwhile, than more than
- 80% of what 1003 has been doing ever since they expanded beyond dot one.
-
- Can anyone from the committee who holds this viewpoint offer a reasonable
- defense of it?
- /r$
-
- Volume-Number: Volume 21, Number 123
-
- shar.1003.2.c.24121
- echo 1003.4.A
- cat >1003.4.A <<'shar.1003.4.A.24121'
- From std-unix-request@uunet.uu.net Tue Sep 25 20:31:03 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA16054; Tue, 25 Sep 90 20:31:03 -0400
- Posted-Date: 25 Sep 90 23:09:38 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <544@usenix.ORG>
- References: <539@usenix.ORG> <541@usenix.ORG> <543@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: IR
- X-Submissions: std-unix@uunet.uu.net
- Date: 25 Sep 90 23:09:38 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
-
- In article <543@usenix.ORG> henry@zoo.toronto.edu (Henry Spencer) writes:
- > In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
- > >In the filesystem abstraction, you open a filename in one stage. You
- > >can't do anything between initiating the open and finding out whether or
- > >not it succeeds. This just doesn't match reality, and it places a huge
- > >restriction on programs that want to do something else while they
- > >communicate.
- > Programs that want to do two things at once should use explicit parallelism,
- > e.g. some sort of threads facility. In every case I've seen, this yielded
- > vastly superior code, with clearer structure and better error handling.
-
- I agree that programs that want to do two things at once should use
- threads. However, a program that sends out several connection requests
- is *not*, in fact, doing several things at once. open() forces it into
- an unrealistic local model; surely you agree that this is not a good
- semantic match for what actually goes on.
-
- That example shows what goes wrong when locality disappears. As another
- example, NFS (as it is currently implemented) shows what goes wrong when
- reliability disappears. Have you ever run ``df'' on a Sun, only to have
- it hang and lock up your terminal? Your process is stuck in kernel mode,
- waiting for an NFS server that may be flooded with requests or may have
- crashed. Programs that use the filesystem for IPC assume that their
- files won't just disappear; this isn't true under NFS.
-
- I am not saying that networked filesystems are automatically a bad
- thing. Quite the contrary: a distributed filesystem with caching and
- other forms of replication can easily be local and reliable, and I'll
- gladly see standard UNIX make provisions for it. But something that's
- not local, or not reliable, or not static, is also not necessarily
- appropriate for the filesystem.
-
- ---Dan
-
- Volume-Number: Volume 21, Number 132
-
- shar.1003.4.A.24121
- echo 1003.4.B
- cat >1003.4.B <<'shar.1003.4.B.24121'
- From std-unix-request@uunet.uu.net Wed Sep 26 17:30:40 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA19979; Wed, 26 Sep 90 17:30:40 -0400
- Posted-Date: 26 Sep 90 12:19:06 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: ske@pkmab.se (Kristoffer Eriksson)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <545@usenix.ORG>
- References: <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: Peridot Konsult i Mellansverige AB, Oerebro, Sweden
- X-Submissions: std-unix@uunet.uu.net
- Date: 26 Sep 90 12:19:06 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: ske@pkmab.se (Kristoffer Eriksson)
-
- In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
- >In the filesystem abstraction, you open a filename in one stage. [...]
- >
- >You can easily construct other examples, but one should be enough to
- >convince you that open() just isn't sufficiently general for everything
- >that you might read() or write().
-
- What prevents us from inventing a few additional filesystem operations
- that ARE general enough?
-
- I think the important thing about the filesystem abstraction that is being
- debated here, is the idea of a common name space, and that idea does not
- require open() to be an indivicible operation, and it does not require that
- open() must be the only way to associate a file descriptor to a named object,
- as long as there is only one name space.
- --
- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
- Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se
- Fax: +46 19-11 51 03 ! or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske
-
- Volume-Number: Volume 21, Number 133
-
- shar.1003.4.B.24121
- echo 1003.4.C
- cat >1003.4.C <<'shar.1003.4.C.24121'
- From std-unix-request@uunet.uu.net Wed Sep 26 17:30:54 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA20052; Wed, 26 Sep 90 17:30:54 -0400
- Posted-Date: 26 Sep 90 18:52:59 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: henry@zoo.toronto.edu (Henry Spencer)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <546@usenix.ORG>
- References: <539@usenix.ORG> <541@usenix.ORG> <543@usenix.ORG> <544@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: U of Toronto Zoology
- X-Submissions: std-unix@uunet.uu.net
- Date: 26 Sep 90 18:52:59 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
-
- In article <544@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
- >> Programs that want to do two things at once should use explicit parallelism,
- >> e.g. some sort of threads facility. In every case I've seen, this yielded
- >> vastly superior code, with clearer structure and better error handling.
- >
- >I agree that programs that want to do two things at once should use
- >threads. However, a program that sends out several connection requests
- >is *not*, in fact, doing several things at once...
-
- I'm afraid I don't understand: a program that is trying, simultaneously,
- to open several different connections is somehow not doing several things
- at once? I think this is a confusion of implementation with specification.
-
- The program *is* doing several things at once, to wit opening several
- connections at once. If "open" is split into several steps, you can
- implement this in a single-threaded program, crudely, by interleaving
- the steps of the different opens. My point is that the code is cleaner,
- and often details like good error handling are easier, if you admit that
- there is parallel activity here and use explicitly parallel constructs.
- Then an "open" that is ready for step 2 does not need to wait for all
- the others to finish step 1 first. And if you do this, there is no need
- to decompose "open" at all, because each thread just does all the steps
- of one open in sequence. Furthermore, it can then proceed to do other
- useful setup chores, e.g. initial dialog on its connection, without
- waiting for the others. This is a far more natural model of what's
- going on than forcing everything into one sequential process, and a
- much better match for the semantics of the problem.
- --
- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
- OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
-
- Volume-Number: Volume 21, Number 134
-
- shar.1003.4.C.24121
- echo 1003.4.D
- cat >1003.4.D <<'shar.1003.4.D.24121'
- From std-unix-request@uunet.uu.net Thu Sep 27 13:32:13 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA03547; Thu, 27 Sep 90 13:32:13 -0400
- Posted-Date: 27 Sep 90 01:08:56 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <547@usenix.ORG>
- References: <543@usenix.ORG> <544@usenix.ORG> <546@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: IR
- X-Submissions: std-unix@uunet.uu.net
- Date: 27 Sep 90 01:08:56 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
-
- In article <546@usenix.ORG> henry@zoo.toronto.edu (Henry Spencer) writes:
- > I'm afraid I don't understand: a program that is trying, simultaneously,
- > to open several different connections is somehow not doing several things
- > at once?
-
- Correct. Between sending an open request out upon the network and
- receiving an acknowledgment, the program is not doing anything at all
- related to that connection.
-
- Let me be more specific. Host X, on the Internet, wants to know the
- time. It decides to ask ten hosts around the network for the time.
-
- In reality, here's what happens in X's interaction with Y: X sends to Y
- a request for a connection on port 37. Pause. Y acknowledges. Y sends a
- few bytes back and closes the connection. During the pause, X is doing
- nothing.
-
- But there are several Y's. So X sends out ten requests in sequence. It
- waits. Each Y responds at some point; X collects the responses in
- whatever order they come. Where is it doing any two things at once, let
- alone several?
-
- > The program *is* doing several things at once, to wit opening several
- > connections at once.
-
- ``Opening a connection'' is really an abuse of the language, because a
- network open consists of at least two steps that may come arbitrarily
- far apart. Let me replace it by phrases that honestly describe what the
- computer is doing: ``sending out a connection request, and later
- accepting an acknowledgment.''
-
- Now, out of the requests and acknowledgments going on, what two are
- happening at once? None of them. You're being misled by the terminology.
- ``Opening a connection'' is such a common phrase that we automatically
- accept it as a description of reality, and consequently believe that it
- is well described by open(); but it isn't. The time between request and
- acknowledgment is filled with nothing but a void.
-
- [ combining threads with a one-step open() ]
- > This is a far more natural model of what's
- > going on than forcing everything into one sequential process, and a
- > much better match for the semantics of the problem.
-
- No. It is not an accurate description of what is going on, since an
- open() is implicitly local while a network open is not.
-
- Abstract imagery aside, though, ``naturalness'' is really defined by how
- a concept helps a programmer. BSD's non-blocking connect() and select()
- for connection acceptance, while perhaps not the best-named system
- calls, are extremely easy to work with. They adapt perfectly to network
- programming problems because they accurately reflect what the system is
- doing. In contrast, forking off threads and kludging around a local
- open() is unnecessarily complex and would make network programming
- unnecessarily difficult. For me that condemns it as an unnatural,
- inaccurate reflection of reality.
-
- ---Dan
-
- Volume-Number: Volume 21, Number 135
-
- shar.1003.4.D.24121
- echo 1003.4.E
- cat >1003.4.E <<'shar.1003.4.E.24121'
- From std-unix-request@uunet.uu.net Thu Sep 27 13:33:06 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA03783; Thu, 27 Sep 90 13:33:06 -0400
- Posted-Date: 24 Sep 90 21:56:28 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <548@usenix.ORG>
- References: <495@usenix.ORG> <523@usenix.ORG> <529@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: IR
- X-Submissions: std-unix@uunet.uu.net
- Date: 24 Sep 90 21:56:28 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
-
- In article <529@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
- > According to fouts@bozeman.bozeman.ingr (Martin Fouts):
- > >However, the presences of the proc file system is not a strong arguement
- > >for the inclusion of othere features in the file system.
- > I disagree. I consider it an excellent example of how the designers
- > of Unix realize that all named objects potentially visible to more
- > than one process belong in the filesystem namespace.
-
- I disagree. I consider it an excellent example of how the designers of
- UNIX realize that all *reliable*, *static*, *local* (or virtually local)
- I/O objects potentially visible to more than one process belong in the
- filesystem namespace.
-
- /dev/proc, for example, is reliable---there's no chance of arbitrary
- failure. It's static---processes have inertia, and stick around until
- they take the positive action of exit()ing. And it's local---you don't
- have an arbitrary delay before seeing the information. So it's a
- perfectly fine thing to include in the filesystem without hesitation.
-
- Objects that aren't reliable, or aren't static, or aren't local, also
- aren't necessarily sensible targets of an open(). Some of them might fit
- well, but each has to be considered on its own merits.
-
- > So, how do we program in such a system? We use its elegant interface
- > -- or should I say "interfaces"? Plain files, devices, IPCs, and
- > network connections each have a semantically accurate interface, which
- > unfortunately makes it different from all others.
-
- The single UNIX interface is the file descriptor. You can read() or
- write() reasonable I/O objects through file descriptors. Very few
- programs---the shell is a counterexample---need to worry about what it
- takes to set up those file descriptors. Very few programs---stty is a
- counterexample---need to know the ioctl()s or other functions that
- control the I/O more precisely. What is your complaint?
-
- ---Dan
-
- Volume-Number: Volume 21, Number 136
-
- shar.1003.4.E.24121
- echo 1003.4.F
- cat >1003.4.F <<'shar.1003.4.F.24121'
- From std-unix-request@uunet.uu.net Thu Sep 27 13:32:28 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA03619; Thu, 27 Sep 90 13:32:28 -0400
- Posted-Date: 27 Sep 90 02:06:52 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <549@usenix.ORG>
- References: <539@usenix.ORG> <541@usenix.ORG> <545@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: IR
- X-Submissions: std-unix@uunet.uu.net
- Date: 27 Sep 90 02:06:52 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
-
- In article <545@usenix.ORG> ske@pkmab.se (Kristoffer Eriksson) writes:
- > In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
- [ file descriptors are general; the filesystem is not ]
- > What prevents us from inventing a few additional filesystem operations
- > that ARE general enough?
-
- That's a good question. I am willing to believe that a somewhat
- different kind of filesystem could sensibly handle I/O objects that are
- neither reliable nor local. I find it somewhat harder to believe that
- the concept of a filesystem can reasonably reflect dynamic I/O:
- information placed into a filesystem should stick around until another
- explicit action.
-
- In any case, you'll have to invent those operations first.
-
- > I think the important thing about the filesystem abstraction that is being
- > debated here, is the idea of a common name space,
-
- Here's what I thought upon reading this.
-
- First: ``A common name space is irrelevant to the most important
- properties of a filesystem.''
-
- Second: ``A common name space is impossible.''
-
- And finally: ``We already have a common name space.''
-
- Let me explain. My first thought was that the basic purpose of a
- filesystem---to provide reliable, static, local I/O---didn't require a
- common name space. As long as there's *some* way to achieve that goal,
- you have a filesystem. UNIX has not only some way, but a uniform,
- consistent, powerful way: file descriptors.
-
- But that's dodging your question. Just because a common name space is
- irrelevant to I/O doesn't mean that it may not be helpful for some other
- reason. My second thought was that the kind of name space you want is
- impossible. You want to include network objects, but no system can
- possibly keep track of the tens of thousands of ports under dozens of
- protocols on hundreds of thousands of computer. It's just too big.
-
- But that's not what you're looking for. Although the name space is huge,
- any one computer only looks at a tiny corner of that space. You only
- need to see ``current'' names. My third thought: We already have that
- common name space! (file,/bin/sh) is in that space. (host,128.122.142.2)
- is in that space. (proc,1) is in that space. No system call uses this
- common name space, but it's there. Use it at will.
-
- ---Dan
-
- Volume-Number: Volume 21, Number 137
-
- shar.1003.4.F.24121
- echo 1003.4.G
- cat >1003.4.G <<'shar.1003.4.G.24121'
- From std-unix-request@uunet.uu.net Fri Sep 28 00:31:11 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA27875; Fri, 28 Sep 90 00:31:11 -0400
- Posted-Date: 27 Sep 90 17:08:13 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: tct!chip@cs.utexas.edu (Chip Salzenberg)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <550@usenix.ORG>
- References: <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: Teltronics/TCT, Sarasota, FL
- X-Submissions: std-unix@uunet.uu.net
- Date: 27 Sep 90 17:08:13 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: chip@tct.uucp (Chip Salzenberg)
-
- According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
- >The underlying principle is that everything is a file *descriptor*.
-
- No one disputes the significance of file descriptors.
-
- Nevertheless, it is important not to underestimate the simplification
- gained by using one namespace for all objects -- files, devices,
- processes, hosts, IPC entities, etc. A filesystem is good for files,
- but a namespace is good for everything. And if an object has a name,
- and you want a file descriptor referring to that object, why invent a
- new system call? I'd rather continue using open().
-
- >In reality, you initiate a network stream connection in two stages.
- >First you send off a request, which wends its way through the network.
- >*Some time later*, the response arrives.
-
- This situation is easily modeled with open() and O_NDELAY. Compare
- the way Unix opens a modem control tty. Normally, the open() call
- will block until the carrier detect line is asserted. However, the
- O_NDELAY parameter to open() avoid the blockage.
-
- Likewise, an open() on a TCP connection would block until the
- connection succeeds or fails. However, the O_NDELAY parameter would
- allow the program to continue immediately, with provisional status of
- "success". The program could come back and check on the open() status
- later, perhaps with an fcntl() call.
-
- Devices are well-entrenched residents of the filesystem namespace. So
- far, all proposed reasons for keeping network connections out of the
- filesystem would apply equally to devices. Do we really want to leave
- the filesytem free of everything except files? That way lay CP/M.
- --
- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
-
- Volume-Number: Volume 21, Number 138
-
- shar.1003.4.G.24121
- echo 1003.4.H
- cat >1003.4.H <<'shar.1003.4.H.24121'
- From std-unix-request@uunet.uu.net Fri Sep 28 00:36:06 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA29892; Fri, 28 Sep 90 00:36:06 -0400
- Posted-Date: 27 Sep 90 17:14:30 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: tct!chip@cs.utexas.edu (Chip Salzenberg)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <551@usenix.ORG>
- References: <541@usenix.ORG> <543@usenix.ORG> <544@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: Teltronics/TCT, Sarasota, FL
- X-Submissions: std-unix@uunet.uu.net
- Date: 27 Sep 90 17:14:30 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: chip@tct.uucp (Chip Salzenberg)
-
- According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
- >NFS (as it is currently implemented) shows what goes wrong when
- >reliability disappears.
-
- In a discussion of filesystem semantics, NFS is a straw man. Everyone
- knows it's a botch.
-
- If AFS and RFS don't convince one that a networked filesystem
- namespace can work well, then nothing will.
- --
- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
-
- Volume-Number: Volume 21, Number 139
-
- shar.1003.4.H.24121
- echo 1003.4.I
- cat >1003.4.I <<'shar.1003.4.I.24121'
- From std-unix-request@uunet.uu.net Fri Sep 28 00:39:36 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA01083; Fri, 28 Sep 90 00:39:36 -0400
- Posted-Date: 27 Sep 90 12:55:49 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: rja7m@plaid.cs.Virginia.EDU (Ran Atkinson)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <552@usenix.ORG>
- References: <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG> <545@usenix.ORG>
- Sender: jsq@usenix.ORG
- Reply-To: randall@Virginia.EDU (Randall Atkinson)
- Organization: University of Virginia
- X-Submissions: std-unix@uunet.uu.net
- Date: 27 Sep 90 12:55:49 GMT
- To: std-unix@uunet.uu.net
-
- Submitted-by: rja7m@plaid.cs.Virginia.EDU (Ran Atkinson)
-
- In article <545@usenix.ORG> ske@pkmab.se (Kristoffer Eriksson) writes:
-
- >What prevents us from inventing a few additional filesystem operations
- >that ARE general enough?
-
- PLEASE. Let's don't go off inventing new things as part of a standards
- effort. The proper way to approach standardisation is to standardise
- the existing practice and avoid all new inventions that haven't been
- fully implemented and tested widely. Many of the problems with UNIX-derived
- OSs have come from folks who didn't do this and ended up with stuff that
- wasn't really compatible with the rest of the OS in function or approach.
-
- A lot of the problems I see coming out of the working groups in P1003
- come from folks failing to standardise existing practice and instead
- going off and inventing a new idea in the committee that hasn't been
- implemented and lacks adequate actual experience with whether the idea
- really works and is a general solution to a real problem.
-
- Randall Atkinson
- randall@Virginia.EDU
-
- Volume-Number: Volume 21, Number 140
-
- shar.1003.4.I.24121
- echo 1003.4.J
- cat >1003.4.J <<'shar.1003.4.J.24121'
- From std-unix-request@uunet.uu.net Fri Sep 28 00:43:28 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA02402; Fri, 28 Sep 90 00:43:28 -0400
- Posted-Date: 27 Sep 90 20:03:39 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: tct!chip@cs.utexas.edu (Chip Salzenberg)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <553@usenix.ORG>
- References: <524@usenix.ORG> <528@usenix.ORG> <540@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: Teltronics/TCT, Sarasota, FL
- X-Submissions: std-unix@uunet.uu.net
- Date: 27 Sep 90 20:03:39 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: chip@tct.uucp (Chip Salzenberg)
-
- According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
- >On the contrary: Given file descriptors, the filesystem is an almost
- >useless abstraction.
-
- Characterizing the Unix filesystem as "almost useless" is, frankly,
- hogwash. A hierarchical filesystem with mount points is a simple, yet
- powerful, organizational tool.
-
- To get back to the original point of this thread, one of my primary
- complaints about the System V IPC facilities is that they all live in
- a flat namespace. There is no way for me to create a subdirectory for
- my application, with naturally named IPCs within that directory. Such
- hierarchical division is "almost useless?" Hardly.
-
- >Many of us are convinced that open() and rename() and unlink() and so on
- >are an extremely poor match for unreliable or dynamic or remote I/O.
-
- Given Unix, where devices -- even those with removable media -- are
- accessed through the filesystem, I can see no reason whatsoever to
- treat network connections and other IPC facilities differently.
- --
- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
-
- Volume-Number: Volume 21, Number 141
-
- shar.1003.4.J.24121
- echo 1003.4.K
- cat >1003.4.K <<'shar.1003.4.K.24121'
- From std-unix-request@uunet.uu.net Fri Sep 28 14:39:23 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA20823; Fri, 28 Sep 90 14:39:23 -0400
- Posted-Date: 28 Sep 90 16:06:42 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: gwyn@smoke.brl.mil (Doug Gwyn)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <556@usenix.ORG>
- References: <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
- X-Submissions: std-unix@uunet.uu.net
- Date: 28 Sep 90 16:06:42 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
-
- In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
- >In the filesystem abstraction, you open a filename in one stage. You
- >can't do anything between initiating the open and finding out whether or
- >not it succeeds. This just doesn't match reality, and it places a huge
- >restriction on programs that want to do something else while they
- >communicate.
-
- UNIX was designed explicitly on the model of communicating sequential
- processes. Each process acts as though it executes in a single thread,
- blocking when it accesses a resource that is not immediately ready.
- While it would be easy to argue that there is a need for improved IPC,
- I haven't heard any convincing arguments for making asynchronity
- explcitly visible to a process. In fact, it was considered quite a
- step forward in computing back in the old days ("THE" operating system,
- for example) when viable means of hiding asynchronity were developed.
-
- Volume-Number: Volume 21, Number 144
-
- shar.1003.4.K.24121
- echo 1003.4.L
- cat >1003.4.L <<'shar.1003.4.L.24121'
- From std-unix-request@uunet.uu.net Fri Sep 28 14:40:51 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA21400; Fri, 28 Sep 90 14:40:51 -0400
- Posted-Date: 28 Sep 90 16:00:33 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: gwyn@smoke.brl.mil (Doug Gwyn)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <557@usenix.ORG>
- References: <524@usenix.ORG> <528@usenix.ORG> <540@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
- X-Submissions: std-unix@uunet.uu.net
- Date: 28 Sep 90 16:00:33 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
-
- In article <540@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
- >You must convince us that open() makes sense for everything that might
- >be a file descriptor, ...
-
- open() provides a mechanism for obtaining the object's handle ("file
- descriptor") in the first place. The argument is really about whether
- there ought to be more than one way to originate such a handle. (dup(),
- fork(), etc. merely propagate a handle obtained by other means.) It is
- possible, as I described over a year ago in the now-defunct
- comp.unix.wizards newsgroup, to design a UNIX-like operating system
- where "it takes a handle to get a handle". However, UNIX is definitely
- not like that. From a software engineering viewpoint, if a single
- mechanism for originating handles will suffice, then that is the best
- approach.
-
- The hierarchical filesystem serves a useful function that you neglected
- to mention: It provides "nodes" at which objects have an opportunity
- to contribute to decisions during interpretation of pathnames. For
- example, a directory node plays a very important organizational role,
- a device driver node acts like a "portal", nodes act as mount points,
- and so on. Without an identifiable node structure the system would be
- severely emaciated. Indeed, Plan 9 exploits this even more heavily
- than does UNIX.
-
- Volume-Number: Volume 21, Number 145
-
- shar.1003.4.L.24121
- echo 1003.4.M
- cat >1003.4.M <<'shar.1003.4.M.24121'
- From std-unix-request@uunet.uu.net Sat Sep 29 18:14:17 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA02826; Sat, 29 Sep 90 18:14:17 -0400
- Posted-Date: 29 Sep 90 17:07:37 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: peter@ficc.ferranti.com (Peter da Silva)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <106697@uunet.UU.NET>
- References: <495@usenix.ORG> <523@usenix.ORG> <529@usenix.ORG> <548@usenix.ORG>
- Sender: jsq@uunet.uu.net
- Reply-To: peter@ficc.ferranti.com (Peter da Silva)
- Organization: Xenix Support, FICC
- X-Submissions: std-unix@uunet.uu.net
- Date: 29 Sep 90 17:07:37 GMT
- To: std-unix@uunet.uu.net
-
- Submitted-by: peter@ficc.ferranti.com (Peter da Silva)
-
- In article <548@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
- > I disagree. I consider it an excellent example of how the designers of
- > UNIX realize that all *reliable*, *static*, *local* (or virtually local)
- > I/O objects potentially visible to more than one process belong in the
- > filesystem namespace.
-
- Like "/dev/tty"? I think you've got some semantic gap here between what's
- appropriate for a file versus what's appropriate for a file descriptor. An
- arbitrary failure on an open file descriptor causes problems... but that
- doesn't keep socket() from returning an fd. An arbitrary failure or an
- arbitrary delay on an open call is perfectly reasonable: programs expect
- open to fail. They depend on write() working.
-
- And serial lines are subject to all the "hazardous" behaviour of network
- connections. An open can be indefinitely deferred. The connection, especially
- over a modem, can vanish at any time. Why not take *them* out of the namespace
- as well?
-
- > You can read() or
- > write() reasonable I/O objects through file descriptors. Very few
- > programs---the shell is a counterexample---need to worry about what it
- > takes to set up those file descriptors.
-
- And that's the problem, because the shell is the program that is used to
- create more file descriptors than just about anything else. If the shell
- had a syntax for creating sockets and network connections we wouldn't be
- having this discussion... but then if it did then you might as well make
- it be via filenames...
-
- And look where this discussion started... over shared memory and messages
- and semaphores being in a separate namespace. But shared memory and message
- ports are all:
-
- reliable,
- static,
- and local...
-
- at least as much as processes.
- --
- Peter da Silva. `-_-'
- +1 713 274 5180. 'U`
- peter@ferranti.com
-
- Volume-Number: Volume 21, Number 150
-
- shar.1003.4.M.24121
- echo 1003.4.N
- cat >1003.4.N <<'shar.1003.4.N.24121'
- From std-unix-request@uunet.uu.net Mon Oct 1 14:32:33 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA02701; Mon, 1 Oct 90 14:32:33 -0400
- Posted-Date: 1 Oct 90 14:59:12 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: peter@ficc.ferranti.com (Peter da Silva)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <566@usenix.ORG>
- References: <543@usenix.ORG> <544@usenix.ORG> <546@usenix.ORG> <547@usenix.ORG>
- Sender: jsq@usenix.ORG
- Reply-To: peter@ficc.ferranti.com (Peter da Silva)
- Organization: Xenix Support, FICC
- X-Submissions: std-unix@uunet.uu.net
- Date: 1 Oct 90 14:59:12 GMT
- To: std-unix@uunet.uu.net
-
- Submitted-by: peter@ficc.ferranti.com (Peter da Silva)
-
- In article <547@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
- > ``Opening a connection'' is such a common phrase that we automatically
- > accept it as a description of reality, and consequently believe that it
- > is well described by open(); but it isn't. The time between request and
- > acknowledgment is filled with nothing but a void.
-
- There are a *number* of cases in UNIX where an open() does not return in
- a determinable time. The correct solution to this is not to pull stuff out
- of the file system, but to provide an asynchronous open() call (that can
- well be hidden by a threads library, but the mechanism should be there).
-
- This is related to the issue of whether network end-points belong in the
- file system, but it is not the same issue because there's much more than
- networks involved... including objects (serial ports with modem control,
- in particular) that are already in the filesystem.
-
- Oddly enough, the latest draft of P1003.4 that I have available does NOT
- include an asynchronous OPEN request. This is a serious omission.
- --
- Peter da Silva. `-_-'
- +1 713 274 5180. 'U`
- peter@ferranti.com
-
- Volume-Number: Volume 21, Number 158
-
- shar.1003.4.N.24121
- echo 1003.4.O
- cat >1003.4.O <<'shar.1003.4.O.24121'
- From std-unix-request@uunet.uu.net Mon Oct 1 14:34:11 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA03632; Mon, 1 Oct 90 14:34:11 -0400
- Posted-Date: 1 Oct 90 16:26:18 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: donn@hpfcrn.fc.hp.com (Donn Terry)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <107020@uunet.UU.NET>
- References: <106697@uunet.UU.NET>
- Sender: jsq@uunet.uu.net
- X-Submissions: std-unix@uunet.uu.net
- Date: 1 Oct 90 16:26:18 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: donn@hpfcrn.fc.hp.com (Donn Terry)
-
- I've been following this discussion on the issues of filesystem namespace.
-
- I'd like to step back from the details and look at it a little
- more philosophically. I think that that may lead to a resolution of the
- issues (or at least some progress) (or a decrease in the shrillness)
- (or something).
-
- UNIX was designed to simplify the programmer's life. In particular,
- anything that could be reasonably generalized, was. This generalization
- is not an easy task, and not easy to explain. The genius of Ritchie and
- Thompson was both because they acheived the generalization, and because
- they got others to beleive in it.
-
- The generalization is more difficult to deal with when you are "used to" some
- other model. (I see folks using various propietary systems griping about
- UNIX because it doesn't do everything just the way they are used to.)
- As Dijkstra once observed about BASIC (I paraphrase, not having the quote).
- "The teaching of BASIC should be forbidden because it forever ruins
- students from being able to use better languages."
-
- I think that (although he exaggerates) that Dijkstra's comment also applies
- in this case. We all are contaminated to some degree or other by the
- preconceptions we bring with us from other training (be it experience with
- other OSs or something else).
-
- I have some personal concerns about some of the functionality in 1003.4
- because it appears to be based upon models from other, successful,
- implementations, but ones that may not have been through the process of
- generalization. It was R&T's thought that having lots of processes would
- solve such problems, and for the day, it did. Now it doesn't because of
- tightly coupled activities (tasks?) needing "fast" switch time.
-
- To me, threads is the generalization that follows the original philosophy,
- not bringing up the OS-like functions similar to select() to the user.
- (I didn't like threads at first, like many don't; I may still not like the
- details, but they do seem to provide the generalization needed for
- that class of task, without the application writer having to write a
- mini-dispatcher of his/her own.)
-
- The broad context of namespace is similar, to me. What's the
- generalization? I don't really know. My (UNIX flavored) biases say
- that it's the filesystem. However, a generalization, not a statement
- that "my problem is different so must be treated differently", is the
- right answer.
-
- Let me try something for the readers of this group to think about.
-
- The "UNIX Filesystem" really consists of two parts: a heirarchical
- namespace mechanism that currently names objects which are at least
- files, devices, file stores (mounted volumes), and data stream IPC
- mechanisms (OK, FIFOs!). Some systems add other IPC mechanisms
- (Streams, Sockets), and the process space (/proc.) I could go on.
-
- One of the class of objects named in the namespace is ordinary files.
- The set of ordinary files is a collection of flat namespaces, where
- the names are (binary) numbers. (Each mounted volume is an element
- of the collection, and each i-number is a filename. The "real names"
- of files are the volume and i-number pair; that's how you tell if two
- files are identical, not by their names in the namespace, of which
- they may have zero or more.) (The fact that the other object types
- also usually have i-numbers is an accident of implementation.)
-
- Open() is a means to translate from the namespace to a handle on an object.
- It may be that the handle is for an ordinary file, or for some other
- object (as I listed above). Historically, files were the most common
- concept, and the namespace becomes the "filesystem". (The volume/inode
- namespace isn't, and shouldn't be, accessible, because the gateway
- functions that Doug Gwyn mentions are necessary and valuable.)
-
- Given the above three paragraphs, one could consciously separate the
- namespace from the file system further, and then the arguments that
- "a connection is not a file" seems weaker. A "connection" is an object
- in the namespace, and open() gives you a handle on it. Given that you
- know what the object is, you may have to perform additional operations
- on it, or avoid them. (E.g., many programs operate differently based on the
- nature of the object they open; if it's a tty it does ioctl() calls on
- it, if not, it doesn't.)
-
- I'm not yet sure that the "filesystem" namespace is (or is not) the
- right generalization, but a generalization is useful so that we don't
- end up were we were when R&T started out with a bunch of unrelated
- namespaces where, by relating them, common functions could be combined,
- and common operations could be performed commonly. For example, it
- would be a shame if we find that some network objects that were not put
- in the generic namespace could reasonably have the
- open()/read()/write()/close() model applied to them, and because they
- were in a different namespace, this could not be done (easily).
-
- Many exisiting proprietary systems (and even more historical ones) left
- you in the state that a program that sequentially read an ordinary file
- couldn't simply do the same thing to a device (without extra programming,
- anyway). Not looking for the generalization could lead us to the same
- state again for the "newer" technologies.
-
- Donn Terry
- Speaking only for myself.
-
- Volume-Number: Volume 21, Number 161
-
- shar.1003.4.O.24121
- echo 1003.4.P
- cat >1003.4.P <<'shar.1003.4.P.24121'
- From std-unix-request@uunet.uu.net Mon Oct 1 21:37:46 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA18471; Mon, 1 Oct 90 21:37:46 -0400
- Posted-Date: 1 Oct 90 20:02:17 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: henry@zoo.toronto.edu (Henry Spencer)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <107042@uunet.UU.NET>
- References: <543@usenix.ORG> <544@usenix.ORG> <546@usenix.ORG> <547@usenix.ORG>
- Sender: jsq@uunet.uu.net
- Organization: U of Toronto Zoology
- X-Submissions: std-unix@uunet.uu.net
- Date: 1 Oct 90 20:02:17 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
-
- In article <547@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
- >> The program *is* doing several things at once, to wit opening several
- >> connections at once.
- >
- >``Opening a connection'' is really an abuse of the language, because a
- >network open consists of at least two steps that may come arbitrarily
- >far apart...
-
- This is the nub of the issue, and it's a difference in semantic models.
- Dan insists on seeing open as a sequence of operations visible to the
- user, in which case his viewpoint is reasonable. I prefer the Unix
- approach -- the details of an open are none of the user's business,
- only whether it succeeds or fails -- in which case "opening a connection"
- is entirely reasonable terminology, and opening several at once (i.e.
- sending out multiple requests before receiving acknowledgements) is
- indeed doing several things at once, best handled with explicit
- parallelism.
-
- Both models are defensible, but I would sort of hope that in a Unix
- standard, the Unix model would be employed.
-
- It is easy to construct examples where explicit parallelism buys you
- things that the multi-step model can't easily achieve, such as writing
- data from one connection to disk while another one is still exchanging
- startup dialog. One *can* always do this in the multi-step model, but
- it amounts to simulating parallel threads. The main structure of the
- program turns into:
-
- for (;;) {
- wait for something to happen on some connection
- deal with it, in such a way that you never block
- }
-
- which does work, but greatly obscures the structure of what's going on,
- and tends to require all sorts of strange convolutions in "deal with it"
- because of the requirement that it not block. (If it blocks, activity
- on *all* connections blocks with it.) BSDish server code tends to be
- very hard to understand because of exactly this structure. With multiple
- threads, each one can block whenever convenient, and the others still
- make progress. Best of all, the individual threads' code looks like a
- standard Unix program:
-
- open connection
- do reads and writes on it and other things as necessary
- close it
- exit
-
- instead of being interwoven into a single master loop with all the rest.
-
- Almost any program employing select() would be better off using real
- parallelism instead, assuming that costs are similar. (It is easy to
- make costs so high that parallelism isn't practical.)
- --
- Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology
- operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry
-
- Volume-Number: Volume 21, Number 163
-
- shar.1003.4.P.24121
- echo 1003.4.Q
- cat >1003.4.Q <<'shar.1003.4.Q.24121'
- From jsq@cs.utexas.edu Tue Oct 2 13:58:40 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA25842; Tue, 2 Oct 90 13:58:40 -0400
- Posted-Date: 2 Oct 90 16:16:54 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: donn@hpfcrn.fc.hp.com (Donn Terry)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <13103@cs.utexas.edu>
- References: <556@usenix.ORG> <557@usenix.ORG> <106697@uunet.UU.NET> <566@usenix.ORG> <107020@uunet.UU.NET> <107042@uunet.UU.NET>
- Sender: jsq@cs.utexas.edu
- X-Submissions: std-unix@uunet.uu.net
- Date: 2 Oct 90 16:16:54 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: donn@hpfcrn.fc.hp.com (Donn Terry)
-
- I was thinking about this a bit more, and want to propose some food for
- thought on the issue.
-
- Classically, open() is a function that "opens a file descriptor", which
- is where the name comes from.
-
- However, if you think, rather, of open() as "translate from the (filesystem)
- namespace this string, and give me a handle on the object" it actually makes
- more sense.
-
- The operations that can be performed on a file are the classical operators
- applicable to such a handle. However, some are forbidden or meaningless on
- some object types (lseek on FIFOs, ioctl on ordinary files, some fcntls on
- devices), and some have operations only applicable to them (ioctl on
- devices) and no other type. I can easily imagine an object that had none
- of the classical file operations applied to it.
-
- Now, there is also nothing that requires that open() be the only function
- that returns such a generic object handle. Imagine (simple example) a
- a heirarchical namespace that contains all possible character
- bitcodes in the namespace. Open() would not work very well because of the
- null termination and slash rules. However, I can imagine another function
- that takes a char** as an argument, where each element is the name in
- the next level of the heirarchy. (With length in the first byte.) It
- would still return a classical file descriptor. Similarly, maybe the
- punctuation is different, or the notion of "root" is different; generalizing
- open() to "give me a handle in a namespace" may be most useful.
-
- I intend this not as any sort of proposal of something that should or should
- not be done, but as an "icebreaker" in terms of thinking about the problem.
-
- What are the further generalizations we need, how do they make sense and
- fit together, and (the real test of success) what are some of the unexpected
- benefits of the generalization? (Granting that the "biggest" unexpected
- benefit will show up "later".)
-
- Donn Terry
- Speaking only for myself.
-
- Volume-Number: Volume 21, Number 167
-
- shar.1003.4.Q.24121
- echo 1003.4.R
- cat >1003.4.R <<'shar.1003.4.R.24121'
- From jsq@cs.utexas.edu Wed Oct 3 08:33:24 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA25048; Wed, 3 Oct 90 08:33:24 -0400
- Posted-Date: 2 Oct 90 23:04:10 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: fouts@bozeman.bozeman.ingr (Martin Fouts)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <13132@cs.utexas.edu>
- References: <524@usenix.ORG> <528@usenix.ORG> <540@usenix.ORG> <553@usenix.ORG>
- Sender: jsq@cs.utexas.edu
- Organization: INTERGRAPH (APD) -- Palo Alto, CA
- X-Submissions: std-unix@uunet.uu.net
- Date: 2 Oct 90 23:04:10 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: fouts@bozeman.bozeman.ingr (Martin Fouts)
-
- >>>>> On 27 Sep 90 20:03:39 GMT, chip@tct.uucp (Chip Salzenberg) said:
-
- Chip> Given Unix, where devices -- even those with removable media -- are
- Chip> accessed through the filesystem, I can see no reason whatsoever to
- Chip> treat network connections and other IPC facilities differently.
- Chip> --
-
- One reason to not treat every IPC facility as part of the file system:
- Shared memory IPC mechanisms which don't need to be visible to
- processes not participating in the IPC.
-
- Marty
- --
- Martin Fouts
-
- UUCP: ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
- ARPA: apd!fouts@ingr.com
- PHONE: (415) 852-2310 FAX: (415) 856-9224
- MAIL: 2400 Geng Road, Palo Alto, CA, 94303
-
- Moving to Montana; Goin' to be a Dental Floss Tycoon.
- - Frank Zappa
-
-
- Volume-Number: Volume 21, Number 169
-
- shar.1003.4.R.24121
- echo 1003.4.S
- cat >1003.4.S <<'shar.1003.4.S.24121'
- From jsq@cs.utexas.edu Wed Oct 3 08:53:15 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA00821; Wed, 3 Oct 90 08:53:15 -0400
- Posted-Date: 3 Oct 90 09:27:45 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: domo@tsa.co.uk (Dominic Dunlop)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <13135@cs.utexas.edu>
- References: <106697@uunet.UU.NET> <107020@uunet.UU.NET>
- Sender: jsq@cs.utexas.edu
- Reply-To: domo@tsa.co.uk
- Organization: The Standard Answer Ltd.
- X-Submissions: std-unix@uunet.uu.net
- Date: 3 Oct 90 09:27:45 GMT
- To: std-unix@uunet.uu.net
-
- Submitted-by: domo@tsa.co.uk (Dominic Dunlop)
-
- In article <107020@uunet.UU.NET> donn@hpfcrn.fc.hp.com (Donn Terry) writes
- cogently about file system and other name spaces. I'm not going to add
- significantly to what he said, merely embroider a little:
-
- > One of the class of objects named in the namespace is ordinary files.
- > The set of ordinary files is a collection of flat namespaces, where
- > the names are (binary) numbers. (Each mounted volume is an element
- > of the collection, and each i-number is a filename. The "real names"
- > of files are the volume and i-number pair; that's how you tell if two
- > files are identical, not by their names in the namespace, of which
- > they may have zero or more.) (The fact that the other object types
- > also usually have i-numbers is an accident of implementation.)
-
- I'd just like to add that the existing POSIX.1 standard does incorporate
- the concept of ``a per-file system unique identifier for a file'',
- although its ethnic origins have been disguised by calling it a ``file
- serial number'' rather than an i-number. The corresponding field in the
- stat structure is, by no coincidence at all, st_ino.
-
- Donn's point about the need to be able to determine whether two
- ``handles'' (whatever they may be) refer to the same object is a good
- one. It follows that, if new types of object are made accessible
- through filename space, the information returned by stat() (or fstat())
- should be sufficient uniquely to identify each distinct object. Of
- course, where the object is not a conventional file, life becomes more
- complex than simply saying that each unique serial number/device id
- combination refers to a unique object. Although POSIX.1 is
- reticent on the topic because it is studiously avoiding the UNIX-ism of
- major and minor device numbers, we all know that, faced with a device
- file on a UN*X system, we should ignore the serial number, and use only
- the device id in determining uniqueness.
-
- I dare say that, as more types of object appear in filename space (and
- I, for one, should like to see them do so), the question of determining
- uniqueness will become knottier. Suppose, for example, that one used
- filenames as handles for virtual circuits across a wide-area network.
- Conceivably, the number of such circuits could be sufficiently large
- that it will become difficult o shoe-horn a unique identifier into the
- existing stat structure fields. A problem for the future?
-
- --
- Dominic Dunlop
-
- Volume-Number: Volume 21, Number 172
-
- shar.1003.4.S.24121
- echo 1003.4.T
- cat >1003.4.T <<'shar.1003.4.T.24121'
- From jsq@cs.utexas.edu Wed Oct 3 11:08:06 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA14297; Wed, 3 Oct 90 11:08:06 -0400
- Posted-Date: 3 Oct 90 15:46:12 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: jason@cnd.hp.com (Jason Zions)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <13142@cs.utexas.edu>
- Sender: jsq@cs.utexas.edu
- Organization: Hewlett Packard, Information Networks Group
- Subject-References: <13132@cs.utexas.edu> <13135@cs.utexas.edu>
- X-Submissions: std-unix@uunet.uu.net
- Date: 3 Oct 90 15:46:12 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: jason@cnd.hp.com (Jason Zions)
-
- Dominic Dunlop says:
-
- > I dare say that, as more types of object appear in filename space (and
- > I, for one, should like to see them do so), the question of determining
- > uniqueness will become knottier. Suppose, for example, that one used
- > filenames as handles for virtual circuits across a wide-area network.
- > Conceivably, the number of such circuits could be sufficiently large
- > that it will become difficult o shoe-horn a unique identifier into the
- > existing stat structure fields. A problem for the future?
-
- Actually, a problem for today. P1003.8 has to cope with the fact that a
- local file for major 0, minor 0x010100, inode 1234 is *different* from a
- file on some remote machine with the same (major,minor,inode) triplet. But
- adding a new field or fields to the stat structure isn't gonna work;
- expanding that structure will cause many implementations to shatter (i.e.
- break spectacularly). Just cobbling up a major number for some random
- remotely-mounted filesystem is unsatisfactory, unless the cobble is
- persistant over umount/mount operations. (An application starts to run;
- opens file1 on remsys, gets (maj,min,ino). Network goes down, comes up;
- system remounts remsys. App opens file2 on remsys. That major number had
- better be the same for remsys!)
-
- What's needed is a simple routine which can be called to determine if two
- handles point to the same object. It would be nice if there was a routine
- which took as arguments a file handle and a path name and returned true iff
- the path referred to the same file. This routine would be guaranteed by the
- implementor to work for any file-system resident object provided for; e.g.
- an SVR4 implementation would have to be able to tell if a file opened via
- RFS referred to the same underlying file as one opened under NFS.
-
- I don't know if that's sufficient, though; application programmers may be
- using the stat info for other purposes, and a remote_addr field might be a
- good idea. Once P1003.12 decides on a representation for an arbitrary
- network address, which might be considerably larger than an IP address.
-
- Jason Zions
-
- Volume-Number: Volume 21, Number 174
-
- shar.1003.4.T.24121
- echo 1003.4.U
- cat >1003.4.U <<'shar.1003.4.U.24121'
- From jsq@cs.utexas.edu Wed Oct 3 19:18:59 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA29364; Wed, 3 Oct 90 19:18:59 -0400
- Posted-Date: 3 Oct 90 17:19:04 GMT
- Received: by cs.utexas.edu (5.64/1.77)
- From: peter@ficc.ferranti.com (Peter da Silva)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <13156@cs.utexas.edu>
- References: <524@usenix.ORG> <528@usenix.ORG> <540@usenix.ORG> <553@usenix.ORG> <13132@cs.utexas.edu>
- Sender: jsq@cs.utexas.edu
- Reply-To: peter@ficc.ferranti.com (Peter da Silva)
- Organization: Xenix Support, FICC
- X-Submissions: std-unix@uunet.uu.net
- Date: 3 Oct 90 17:19:04 GMT
- To: std-unix@uunet.uu.net
-
- Submitted-by: peter@ficc.ferranti.com (Peter da Silva)
-
- In article <13132@cs.utexas.edu> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
- > One reason to not treat every IPC facility as part of the file system:
- > Shared memory IPC mechanisms which don't need to be visible to
- > processes not participating in the IPC.
-
- Provide an example, considering the advantages of having shell level
- visibility of objects has for (a) debugging, (b) system administration,
- (c) integration, (d)...
-
- It's nice to be able to fake a program out with a shell script.
- --
- Peter da Silva. `-_-'
- +1 713 274 5180. 'U`
- peter@ferranti.com
-
- Volume-Number: Volume 21, Number 176
-
- shar.1003.4.U.24121
- echo 1003.4.V
- cat >1003.4.V <<'shar.1003.4.V.24121'
- From jsq@cs.utexas.edu Thu Oct 4 10:59:16 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA02422; Thu, 4 Oct 90 10:59:16 -0400
- Posted-Date: 4 Oct 90 06:21:55 GMT
- Received: by cs.utexas.edu (5.64/1.77)
- From: aglew@crhc.uiuc.edu (Andy Glew)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <13182@cs.utexas.edu>
- References: <495@usenix.ORG> <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG>
- Sender: jsq@cs.utexas.edu
- Organization: Center for Reliable and High-Performance Computing University of
- X-Submissions: std-unix@uunet.uu.net
- Date: 4 Oct 90 06:21:55 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: aglew@crhc.uiuc.edu (Andy Glew)
-
- >In the filesystem abstraction, you open a filename in one stage. You
- >can't do anything between initiating the open and finding out whether or
- >not it succeeds. This just doesn't match reality, and it places a huge
- >restriction on programs that want to do something else while they
- >communicate.
-
- Sounds like you want an asynchronous open facility, much like the
- asynchronous read and write that others already have on their wish
- list for file I/O (and other I/O) (not everyone believes that multiple
- threads are the way to do asynch I/O).
-
- --
- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
-
- Volume-Number: Volume 21, Number 181
-
- shar.1003.4.V.24121
- echo 1003.4.W
- cat >1003.4.W <<'shar.1003.4.W.24121'
- From jsq@cs.utexas.edu Thu Oct 4 14:39:03 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA20321; Thu, 4 Oct 90 14:39:03 -0400
- Posted-Date: 3 Oct 90 20:49:11 GMT
- Received: by cs.utexas.edu (5.64/1.77)
- From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <13195@cs.utexas.edu>
- References: <529@usenix.ORG> <548@usenix.ORG> <106697@uunet.UU.NET>
- Sender: jsq@cs.utexas.edu
- Organization: IR
- X-Submissions: std-unix@uunet.uu.net
- Date: 3 Oct 90 20:49:11 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
-
- In article <106697@uunet.UU.NET> peter@ficc.ferranti.com (Peter da Silva) writes:
- [ Programs depend on write() working. ]
-
- On the contrary. When the descriptor is unreliable, you get an I/O
- error or the data is simply corrupted; this is exactly what happens with
- disk I/O. Programs that handle errors on read() and write() are more
- robust than programs that don't.
-
- More commonly, when the descriptor is dynamic and the other side drops,
- you get a broken pipe. This is certainly not a rare failure mode.
-
- In context, I said that open() is only appropriate for reliable, static,
- local I/O objects. You seem to be arguing that read() and write(), and
- file descriptors in general, also require reliable, static, local I/O
- objects, and so my distinction is silly. But UDP sockets, pipes, and TCP
- sockets are unreliable, dynamic, and remote file descriptors
- respectively, and read()/write() work with them perfectly.
-
- > > You can read() or
- > > write() reasonable I/O objects through file descriptors. Very few
- > > programs---the shell is a counterexample---need to worry about what it
- > > takes to set up those file descriptors.
- > And that's the problem, because the shell is the program that is used to
- > create more file descriptors than just about anything else. If the shell
- > had a syntax for creating sockets and network connections we wouldn't be
- > having this discussion...
-
- Oh? Really? I have a syntax for creating sockets and network connections
- from my shell. For example, I just checked an address by typing
-
- $ ctcp uunet.uu.net smtp sh -c 'echo expn rsalz>&7;echo quit>&7;cat<&6'
-
- So we shouldn't be having this discussion, right?
-
- > but then if it did then you might as well make
- > it be via filenames...
-
- Why? I don't see a natural filename syntax for TCP connections, so why
- should I try to figure one out? What purpose would it serve? Only two
- programs---a generic client and a generic server---have to understand
- the filenames. If those two programs work, what's the problem?
-
- [ shm and sem are reliable, static, local ]
-
- As a BSD addict I don't have much experience with those features, but I
- believe you're right. So feel free to put shared memory objects into the
- filesystem; I won't argue. Semaphores, I'm not sure about, because it's
- unclear what a file descriptor pointing to a semaphore should mean. Are
- semaphores I/O objects in the first place?
-
- ---Dan
-
- Volume-Number: Volume 21, Number 182
-
- shar.1003.4.W.24121
- echo 1003.4.X
- cat >1003.4.X <<'shar.1003.4.X.24121'
- From jsq@cs.utexas.edu Fri Oct 5 02:37:08 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AB21718; Fri, 5 Oct 90 02:37:08 -0400
- Posted-Date: 3 Oct 90 19:58:02 GMT
- Received: by cs.utexas.edu (5.64/1.77)
- From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <13218@cs.utexas.edu>
- References: <543@usenix.ORG> <544@usenix.ORG> <551@usenix.ORG>
- Sender: jsq@cs.utexas.edu
- Organization: IR
- X-Submissions: std-unix@uunet.uu.net
- Date: 3 Oct 90 19:58:02 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
-
- In article <551@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
- > According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
- > >NFS (as it is currently implemented) shows what goes wrong when
- > >reliability disappears.
- > In a discussion of filesystem semantics, NFS is a straw man. Everyone
- > knows it's a botch.
- > If AFS and RFS don't convince one that a networked filesystem
- > namespace can work well, then nothing will.
-
- Exactly! This example proves my point. What's so bad about NFS---why it
- doesn't fit well into the filesystem---is that it doesn't make the
- remote filesystem reliable and local. If you show me Joe Shmoe's RFS
- with reliable, local, static I/O objects, I'll gladly include it in the
- filesystem.
-
- ---Dan
-
- Volume-Number: Volume 21, Number 185
-
- shar.1003.4.X.24121
- echo 1003.4.Y
- cat >1003.4.Y <<'shar.1003.4.Y.24121'
- From jsq@cs.utexas.edu Fri Oct 5 02:42:14 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA23596; Fri, 5 Oct 90 02:42:14 -0400
- Posted-Date: 4 Oct 90 20:39:37 GMT
- Received: by cs.utexas.edu (5.64/1.77)
- From: tct!chip@cs.utexas.edu (Chip Salzenberg)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <13219@cs.utexas.edu>
- References: <540@usenix.ORG> <553@usenix.ORG> <13132@cs.utexas.edu>
- Sender: jsq@cs.utexas.edu
- Organization: Teltronics/TCT, Sarasota, FL
- X-Submissions: std-unix@uunet.uu.net
- Date: 4 Oct 90 20:39:37 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: chip@tct.uucp (Chip Salzenberg)
-
- According to fouts@bozeman.bozeman.ingr (Martin Fouts):
- >One reason to not treat every IPC facility as part of the file system:
- >Shared memory IPC mechanisms which don't need to be visible to processes
- >not participating in the IPC.
-
- Yes, it is obviously desirable to have IPC entities without names.
- This feature is a simple extension of the present ability to keep a
- plain file open after its link count falls to zero. Of course, the
- committee could botch the job by making it an error to completely
- unlink a live IPC.
- --
- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
-
- Volume-Number: Volume 21, Number 186
-
- shar.1003.4.Y.24121
- echo 1003.4.Z
- cat >1003.4.Z <<'shar.1003.4.Z.24121'
- From std-unix-request@uunet.uu.net Sat Oct 6 17:10:26 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA01003; Sat, 6 Oct 90 17:10:26 -0400
- Posted-Date: 5 Oct 90 19:21:41 GMT
- Received: by cs.utexas.edu (5.64/1.77)
- From: nick@bis.com (Nick Bender)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Summary: write does *not always work*
- Message-Id: <13270@cs.utexas.edu>
- References: <543@usenix.ORG> <544@usenix.ORG> <551@usenix.ORG> <13218@cs.utexas.edu>
- Sender: fletcher@cs.utexas.edu
- Organization: Batterymarch Investment Systems
- X-Submissions: std-unix@uunet.uu.net
- Date: 5 Oct 90 19:21:41 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: nick@bischeops.uucp (Nick Bender)
-
- In article <13218@cs.utexas.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
- = Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
- =
- = In article <551@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
- = > According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
- = > >NFS (as it is currently implemented) shows what goes wrong when
- = > >reliability disappears.
- = > In a discussion of filesystem semantics, NFS is a straw man. Everyone
- = > knows it's a botch.
- = > If AFS and RFS don't convince one that a networked filesystem
- = > namespace can work well, then nothing will.
- =
- = Exactly! This example proves my point. What's so bad about NFS---why it
- = doesn't fit well into the filesystem---is that it doesn't make the
- = remote filesystem reliable and local. If you show me Joe Shmoe's RFS
- = with reliable, local, static I/O objects, I'll gladly include it in the
- = filesystem.
- =
- = ---Dan
-
- Any program which assumes that write(2) always works is broken. Period.
- That's why you sometimes get long streams of "filesystem full" on your
- console when some brain-damaged utility doesn't check a return value.
- In my view this is not a reason to call NFS a botch.
-
- nick@bis.com
-
-
- Volume-Number: Volume 21, Number 188
-
- shar.1003.4.Z.24121
- echo 1003.4.a
- cat >1003.4.a <<'shar.1003.4.a.24121'
- From std-unix-request@uunet.uu.net Fri Aug 24 12:19:40 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA22813; Fri, 24 Aug 90 12:19:40 -0400
- Posted-Date: 24 Aug 90 03:28:06 GMT
- Received: by cs.utexas.edu (5.64/1.71)
- id AA06127; Fri, 24 Aug 90 11:19:35 -0500
- From: peter@ficc.ferranti.com (peter da silva)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <457@usenix.ORG>
- References: <448@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: ficc.ferranti.com!peter@cs.utexas.edu (Peter da Silva)
- Organization: Xenix Support, FICC
- X-Submissions: std-unix@uunet.uu.net
- Date: 24 Aug 90 03:28:06 GMT
- To: std-unix@uunet.uu.net
-
- From: peter@ficc.ferranti.com (peter da silva)
-
- My personal opinion is that *anything* that can go into the file system name
- space *should*. That's what makes UNIX UNIX... that it's all visible from the
- shell...
- ---
- Peter da Silva. `-_-'
- +1 713 274 5180. 'U`
- peter@ferranti.com
-
- Volume-Number: Volume 21, Number 57
-
- shar.1003.4.a.24121
- echo 1003.4.b
- cat >1003.4.b <<'shar.1003.4.b.24121'
- From std-unix-request@uunet.uu.net Mon Aug 27 23:40:58 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA28231; Mon, 27 Aug 90 23:40:58 -0400
- Posted-Date: 27 Aug 90 17:51:57 GMT
- Received: by cs.utexas.edu (5.64/1.74)
- From: tct!chip@cs.utexas.edu (Chip Salzenberg)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <467@usenix.ORG>
- References: <448@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Organization: Teltronics/TCT, Sarasota, FL
- X-Submissions: std-unix@uunet.uu.net
- Date: 27 Aug 90 17:51:57 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: chip@tct.uucp (Chip Salzenberg)
-
- > Finally, the group accepted abandoning the use of
- > file descriptors for semaphore handles, but some participants
- > wanted to keep semaphore names pathnames.
-
- Aargh! Almost everyone realizes that System V IPC is a botch, largely
- because it doesn't live in the filesystem. So what does IEEE do?
- They take IPC out of the filesystem!
-
- What sane reason could there be to introduce Yet Another Namespace?
- --
- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
-
- Volume-Number: Volume 21, Number 65
-
- shar.1003.4.b.24121
- echo 1003.4.c
- cat >1003.4.c <<'shar.1003.4.c.24121'
- From std-unix-request@uunet.uu.net Tue Aug 28 18:20:30 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA04815; Tue, 28 Aug 90 18:20:30 -0400
- Posted-Date: 28 Aug 90 11:58:40 GMT
- Received: by cs.utexas.edu (5.64/1.74)
- From: sp@mysteron.osf.org (Simon Patience)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <470@usenix.ORG>
- References: <448@usenix.ORG> <467@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: sp@mysteron.osf.org (Simon Patience)
- Organization: Open Software Foundation
- X-Submissions: std-unix@uunet.uu.net
- Date: 28 Aug 90 11:58:40 GMT
- To: std-unix@uunet.uu.net
-
- From: sp@mysteron.osf.org (Simon Patience)
-
- In article <467@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
- >From: chip@tct.uucp (Chip Salzenberg)
- >
- >> Finally, the group accepted abandoning the use of
- >> file descriptors for semaphore handles, but some participants
- >> wanted to keep semaphore names pathnames.
- >
- >Aargh! Almost everyone realizes that System V IPC is a botch, largely
- >because it doesn't live in the filesystem. So what does IEEE do?
- >They take IPC out of the filesystem!
- >
- >What sane reason could there be to introduce Yet Another Namespace?
-
- The reason for semaphores not being in the file system is twofold. Some
- realtime embedded systems do not have a file system but do want semaphores
- So this allows them to have them without having to bring in the baggage a
- file system would entail. Secondly, as far as threads, which are supposed to
- be light weight, are concerned it allows semaphores to be implmented in user
- space rather than forcing them into the kernel for the file system.
-
- A good reason for *not* having IPC handles in the file system is to allow
- network IPC to use the same interfaces. If you have IPC handles in the
- file system then two machines who have applications trying to communicate
- would also have to have at least part of their file system name space to
- be shared. This is non trivial to arrange for two machines so can you
- imaging the problem of doing this for 100 (or 1000?) machines.
-
- I am just the messenger for these views and do not necessarily hold them
- myself. They were the reasons that came up during the discussion.
-
- Simon.
-
- Simon Patience Phone: (617) 621-8736
- Open Software Foundation FAX: (617) 225-2782
- 11 Cambridge Center Email: sp@osf.org
- Cambridge MA 02142 uunet!osf.org!sp
-
- Volume-Number: Volume 21, Number 68
-
- shar.1003.4.c.24121
- echo 1003.4.d
- cat >1003.4.d <<'shar.1003.4.d.24121'
- From std-unix-request@uunet.uu.net Wed Aug 29 18:18:41 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA03017; Wed, 29 Aug 90 18:18:41 -0400
- Posted-Date: 29 Aug 90 14:01:44 GMT
- Received: by cs.utexas.edu (5.64/1.75)
- From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <475@usenix.ORG>
- References: <448@usenix.ORG> <467@usenix.ORG> <470@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Organization: NCR Microelectronics, Ft. Collins, CO
- X-Submissions: std-unix@uunet.uu.net
- Date: 29 Aug 90 14:01:44 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)
-
- >>>>> On 28 Aug 90 11:58:40 GMT, sp@mysteron.osf.org (Simon Patience) said:
- >> Finally, the group accepted abandoning the use of
- >> file descriptors for semaphore handles, but some participants
- >> wanted to keep semaphore names pathnames.
- >>
- >Aargh! Almost everyone realizes that System V IPC is a botch, largely
- >because it doesn't live in the filesystem. So what does IEEE do?
- >They take IPC out of the filesystem!
- >
- >What sane reason could there be to introduce Yet Another Namespace?
-
- Simon> The reason for semaphores not being in the file system is twofold.
- Simon> Some realtime embedded systems do not have a file system but do want
- Simon> semaphores...
-
- Simon> A good reason for *not* having IPC handles in the file system is to
- Simon> allow network IPC to use the same interfaces.
-
- How about adding non-file-system-based "handles" to an mmap-like interface?
- (e.g. shmmap(host,porttype,portnum,addr,len,prot,flags)?) This could
- allow the same interface to be used for network and non-network IPC,
- without the overhead of a trap for every non-network IPC transaction.
-
- `Scuse me while I don my flame retardant suit... :-)
-
- #include <std/disclaimer.h>
- --
- Chuck Phillips MS440
- NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com
- 2001 Danfield Ct.
- Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckp
-
- Volume-Number: Volume 21, Number 72
-
- shar.1003.4.d.24121
- echo 1003.4.e
- cat >1003.4.e <<'shar.1003.4.e.24121'
- From std-unix-request@uunet.uu.net Thu Aug 30 14:18:37 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA03070; Thu, 30 Aug 90 14:18:37 -0400
- Posted-Date: 30 Aug 90 12:31:01 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: tct!chip@cs.utexas.edu (Chip Salzenberg)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <477@usenix.ORG>
- References: <448@usenix.ORG> <467@usenix.ORG> <470@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Organization: Teltronics/TCT, Sarasota, FL
- X-Submissions: std-unix@uunet.uu.net
- Date: 30 Aug 90 12:31:01 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: chip@tct.uucp (Chip Salzenberg)
-
- According to sp@mysteron.osf.org (Simon Patience):
- >Some realtime embedded systems do not have a file system but do want
- >semaphores. So this allows them to have them without having to bring
- >in the baggage a file system would entail.
-
- I was under the impression that POSIX was designing a portable Unix
- interface. Without a filesystem, you don't have Unix, do you?
- Besides, a given embedded system's library could easily emulate a
- baby-simple filesystem.
-
- >Secondly, as far as threads, which are supposed to be light weight,
- >are concerned it allows semaphores to be implmented in user space
- >rather than forcing them into the kernel for the file system.
-
- The desire for user-space support indicates to me that there should be
- some provision for non-filesystem (anonymous) IPCs that can be created
- and used without kernel intervention. This need does not reduce the
- desirability of putting global IPCs in the filesystem.
-
- >A good reason for *not* having IPC handles in the file system is to allow
- >network IPC to use the same interfaces.
-
- Filesystem entities can be used to trigger network activity by the
- kernel (or its stand-in), even if they do not reside on shared
- filesystems.
- --
- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
-
- Volume-Number: Volume 21, Number 74
-
- shar.1003.4.e.24121
- echo 1003.4.f
- cat >1003.4.f <<'shar.1003.4.f.24121'
- From std-unix-request@uunet.uu.net Thu Aug 30 14:19:34 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA03268; Thu, 30 Aug 90 14:19:34 -0400
- Posted-Date: 30 Aug 90 15:07:04 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: preece@urbana.mcd.mot.com (Scott E. Preece)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <478@usenix.ORG>
- References: <448@usenix.ORG> <467@usenix.ORG> <470@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Organization: Motorola MCD, Urbana Design Center
- X-Submissions: std-unix@uunet.uu.net
- Date: 30 Aug 90 15:07:04 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: preece@urbana.mcd.mot.com (Scott E. Preece)
-
- | From: sp@mysteron.osf.org (Simon Patience)
-
- | The reason for semaphores not being in the file system is twofold. Some
- | realtime embedded systems do not have a file system but do want semaphores
- | So this allows them to have them without having to bring in the baggage a
- | file system would entail.
- ---
- I don't care whether they have something that looks like UNIX filesystem
- code or not, or whether they have disk drives or not, but I don't think
- it's unreasonable to require them to handle semaphore names as though
- they were in a filesystem namespace. Otherwise you're going to end up
- with a collection of independent features, each minimally specified so
- that it can work without assuming anything else, and anyone with any
- sense is going to say "Yuck" and use a real operating system that
- provides reasonable integration and for a uniform notion of, among other
- things, naming.
- ---
- | ... Secondly, as far as threads, which are supposed to
- | be light weight, are concerned it allows semaphores to be implmented in user
- | space rather than forcing them into the kernel for the file system.
- ---
- Eh? I don't know what the group has proposed since the ballot, but it
- would seem that using a filesystem name only makes a difference when you
- first specify you're going to be looking at a particular semaphore,
- which shouldn't be a critical path event. After that you use a file
- descriptor, which I think could be handled in user space about as well
- as anything else. In either case you're going to have to go to the
- kernel when scheduling is required (when you block or when you release
- the semaphore).
- ---
- | A good reason for *not* having IPC handles in the file system is to allow
- | network IPC to use the same interfaces. If you have IPC handles in the
- | file system then two machines who have applications trying to communicate
- | would also have to have at least part of their file system name space to
- | be shared. This is non trivial to arrange for two machines so can you
- | imaging the problem of doing this for 100 (or 1000?) machines.
- ---
- You're going to have to synchronize *some* namespace anyway, why
- shouldn't it be a piece of the filesystem namespace?
-
- A consistent approach to naming and name resolution for ALL global
- objects should be one of the basic requirements for any new POSIX (or
- UNIX!) functionality. We should have *one* namespace so that we can
- write general tools that only need to know about one namespace.
- --
- scott preece
- motorola/mcd urbana design center 1101 e. university, urbana, il 61801
- uucp: uunet!uiucuxc!udc!preece, arpa: preece@urbana.mcd.mot.com
-
- Volume-Number: Volume 21, Number 75
-
- shar.1003.4.f.24121
- echo 1003.4.g
- cat >1003.4.g <<'shar.1003.4.g.24121'
- From std-unix-request@uunet.uu.net Fri Aug 31 12:19:45 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA05179; Fri, 31 Aug 90 12:19:45 -0400
- Posted-Date: 31 Aug 90 12:25:17 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: kingdon@ai.mit.edu (Jim Kingdon)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <479@usenix.ORG>
- Sender: std-unix@usenix.ORG
- X-Submissions: std-unix@uunet.uu.net
- Date: 31 Aug 90 12:25:17 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: kingdon@ai.mit.edu (Jim Kingdon)
-
- One obvious (if a little wishy-washy) solution is to not specify
- whether the namespaces are the same. That is, applications are
- required to use a valid path, and have to be prepared for things like
- unwritable directories, but implementations are not required to check
- for those things.
-
- This makes sense in light of the fact that there seems to be a general
- lack of consensus about which is best. Even though there is existing
- practice for both ways of doing things, it may be premature to
- standardize either behavior now.
-
- Volume-Number: Volume 21, Number 76
-
- shar.1003.4.g.24121
- echo 1003.4.h
- cat >1003.4.h <<'shar.1003.4.h.24121'
- From std-unix-request@uunet.uu.net Fri Aug 31 13:18:45 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA22560; Fri, 31 Aug 90 13:18:45 -0400
- Posted-Date: 31 Aug 90 12:51:35 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: edj@trazadone.westford.ccur.com (Doug Jensen)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <481@usenix.ORG>
- Sender: std-unix@usenix.ORG
- X-Submissions: std-unix@uunet.uu.net
- Date: 31 Aug 90 12:51:35 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: Doug Jensen <edj@trazadone.westford.ccur.com>
-
- 1003.13 is working on real-time AEP's, including one for small embedded
- real-time systems which does not have a file system. So the POSIX answer
- is yes, without the filesystem you still can have a POSIX-compliant
- interface.
-
- Doug Jensen
- Concurrent Computer Corp.
- edj@westford.ccur.com
-
- Volume-Number: Volume 21, Number 78
-
- shar.1003.4.h.24121
- echo 1003.4.i
- cat >1003.4.i <<'shar.1003.4.i.24121'
- From std-unix-request@uunet.uu.net Thu Sep 6 17:00:11 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA09428; Thu, 6 Sep 90 17:00:11 -0400
- Posted-Date: 5 Sep 90 15:46:10 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: fouts@bozeman.bozeman.ingr (Martin Fouts)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <488@usenix.ORG>
- References: <448@usenix.ORG> <457@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Organization: INTERGRAPH (APD) -- Palo Alto, CA
- X-Submissions: std-unix@uunet.uu.net
- Date: 5 Sep 90 15:46:10 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: fouts@bozeman.bozeman.ingr (Martin Fouts)
-
- >>>>> On 24 Aug 90 03:28:06 GMT, peter@ficc.ferranti.com (peter da silva) said:
- peter> My personal opinion is that *anything* that can go into the file system name
- peter> space *should*. That's what makes UNIX UNIX... that it's all visible from the
- peter> shell...
-
- I'm not sure which Unix you've been running for the past five or more
- years, but a lot of stuff doesn't live in the file system name space
- under various BSD derived systems, nor do the networking types believe
- it belongs there. IMHO neither does a process handle, nor a
- semaphore, and don't even talk to me about "named pipes" as an IPC
- mechanism.
-
- (Gee, I guess reasonable men might differ on what belongs in the name
- space ;-)
-
- Marty
- --
- Martin Fouts
-
- UUCP: ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
- ARPA: apd!fouts@ingr.com
- PHONE: (415) 852-2310 FAX: (415) 856-9224
- MAIL: 2400 Geng Road, Palo Alto, CA, 94303
-
- Moving to Montana; Goin' to be a Dental Floss Tycoon.
- - Frank Zappa
-
- Volume-Number: Volume 21, Number 83
-
- shar.1003.4.i.24121
- echo 1003.4.j
- cat >1003.4.j <<'shar.1003.4.j.24121'
- From std-unix-request@uunet.uu.net Thu Sep 6 19:22:22 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA06538; Thu, 6 Sep 90 19:22:22 -0400
- Posted-Date: 6 Sep 90 21:03:14 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: gwyn@smoke.brl.mil (Doug Gwyn)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <491@usenix.ORG>
- References: <448@usenix.ORG> <457@usenix.ORG> <488@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
- X-Submissions: std-unix@uunet.uu.net
- Date: 6 Sep 90 21:03:14 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: Doug Gwyn <gwyn@smoke.brl.mil>
-
- In article <488@usenix.ORG> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
- >I'm not sure which Unix you've been running for the past five or more
- >years, but a lot of stuff doesn't live in the file system name space
- >under various BSD derived systems, nor do the networking types believe
- >it belongs there.
-
- Excuse me, but the "networking types" I talk to believe that sockets
- were a botch and that network connections definitely DO belong within
- a uniform UNIX "file" name space. Peter was quite right to note that
- this is an essential feature of UNIX's design. In fact there are UNIX
- implementations that do this right, 4BSD is simply not among them yet.
-
- Volume-Number: Volume 21, Number 85
-
- shar.1003.4.j.24121
- echo 1003.4.k
- cat >1003.4.k <<'shar.1003.4.k.24121'
- From std-unix-request@uunet.uu.net Fri Sep 7 12:21:22 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA08917; Fri, 7 Sep 90 12:21:22 -0400
- Posted-Date: 7 Sep 90 02:40:27 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: peter@ficc.ferranti.com (peter da silva)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <493@usenix.ORG>
- References: <448@usenix.ORG> <457@usenix.ORG> <488@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: peter@ficc.ferranti.com (Peter da Silva)
- Organization: Xenix Support, FICC
- X-Submissions: std-unix@uunet.uu.net
- Date: 7 Sep 90 02:40:27 GMT
- To: std-unix@uunet.uu.net
-
- From: peter da silva <peter@ficc.ferranti.com>
-
- In article <488@usenix.ORG> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
- > > My personal opinion is that *anything* that can go into the file system
- > > name space *should*. That's what makes UNIX UNIX... that it's all visible
- > > from the shell...
-
- > I'm not sure which Unix you've been running for the past five or more
- > years, but a lot of stuff doesn't live in the file system name space
- > under various BSD derived systems,
-
- Yes, and there's even more stuff in System V that doesn't live in that
- name space. In both cases it's *wrong*.
-
- > nor do the networking types believe
- > it belongs there.
-
- Some more details on this subject would be advisable. I'm aware that not
- everything *can* go in the file system name space, by the way...
-
- > IMHO neither does a process handle, nor a
- > semaphore, and don't even talk to me about "named pipes" as an IPC
- > mechanism.
-
- An active semaphore can be implemented any way you want, but it should
- be represented by an entry in the name space. The same goes for process
- handles and so on.
-
- Named pipes are an inadequate mechanism for much IPC, but they work quite
- well for many simple cases. If you're looking at them as some sort of
- paragon representing the whole concept, you're sadly mistaken.
-
- Anyway... what is it that makes "dev/win" more worthy of having an entry
- in "/dev" than "dev/socket"?
- --
- Peter da Silva. `-_-'
- +1 713 274 5180. 'U`
- peter@ferranti.com
-
- Volume-Number: Volume 21, Number 87
-
- shar.1003.4.k.24121
- echo 1003.4.l
- cat >1003.4.l <<'shar.1003.4.l.24121'
- From std-unix-request@uunet.uu.net Fri Sep 7 14:20:39 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA22362; Fri, 7 Sep 90 14:20:39 -0400
- Posted-Date: 7 Sep 90 15:23:19 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: tct!chip@cs.utexas.edu (Chip Salzenberg)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <495@usenix.ORG>
- References: <448@usenix.ORG> <457@usenix.ORG> <488@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Organization: Teltronics/TCT, Sarasota, FL
- X-Submissions: std-unix@uunet.uu.net
- Date: 7 Sep 90 15:23:19 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: chip@tct.uucp (Chip Salzenberg)
-
- According to fouts@bozeman.bozeman.ingr (Martin Fouts):
- >I'm not sure which Unix you've been running for the past five or more
- >years, but a lot of stuff doesn't live in the file system name space ...
-
- The absense of sockets (except UNIX domain), System V IPC, etc. from
- the file system is, in the opinion of many, a bug. It is a result of
- Unix being extended by people who do not understand Unix.
-
- Research Unix, which is the result of continued development by the
- creators of Unix, did not take things out of the filesystem. To the
- contrary, it put *more* things there, including processes (via the
- /proc pseudo-directory).
-
- It is true that other operating systems get along without devices,
- IPC, etc. in their filesystems. That's fine for them; but it's not
- relevant to Unix. Unix programming has a history of relying on the
- filesystem to take care of things that other systems handle as special
- cases -- devices, for example. The idea that devices can be files but
- TCP/IP sockets cannot runs counter to all Unix experience.
-
- The reason why I continue this discussion here, in comp.std.unix, is
- that many Unix programmers hope that the people in the standardization
- committees have learned from the out-of-filesystem mistake, and will
- rectify it.
- --
- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
-
- Volume-Number: Volume 21, Number 89
-
- shar.1003.4.l.24121
- echo 1003.4.m
- cat >1003.4.m <<'shar.1003.4.m.24121'
- From std-unix-request@uunet.uu.net Sat Sep 8 09:21:20 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA18377; Sat, 8 Sep 90 09:21:20 -0400
- Posted-Date: 8 Sep 90 00:01:00 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: swart@src.dec.com (Garret Swart)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <497@usenix.ORG>
- References: <481@usenix.ORG> <495@usenix.ORG> <488@usenix.ORG> <491@usenix.ORG> <493@usenix.ORG> <479@usenix.ORG>
- Sender: std-unix@usenix.ORG
- X-Submissions: std-unix@uunet.uu.net
- Date: 8 Sep 90 00:01:00 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: swart@src.dec.com (Garret Swart)
-
- I believe in putting lots of interesting stuff in the file system name
- space but I don't believe that semaphores belong there. The reason
- I don't want to put semaphores in the name space is the same reason
- I don't want to put my program variables in the name space: I want
- to have lots of them, I want to create and destroy them very quickly
- and I want to operate on them even more quickly. In other words, the
- granularity is wrong.
-
- The purpose of a semaphore is to synchronize actions on an object.
- What kinds of objects might one want to synchronize? Generally the
- objects are either OS supplied like devices or files, or user defined
- data structures. The typical way of synchronizing files and devices
- is to use advisory locks or the "exclusive use" mode on the device.
- The more difficult case and the one for which semaphores were invented,
- and later added to Unix, is that of synchronizing user data structures.
-
- In Unix, user data structures may live either in a process's private
- memory or in a shared memory segment. In both cases there are probably
- many different data structures in that memory and many of these data
- structures may need to be synchronized. For maximum concurrency the
- programmer may wish to synchronize each data structure with its own
- semaphore. In many applications these data structures may come and
- go very quickly and the expense of creating a semaphore to synchronize
- the data can be important factor in the performance of the application.
-
- It thus seems more natural to allow semaphores to be efficiently
- allocated along with the data that they are designed to synchronize.
- That is, allow them to be allocated in a process's private address
- space or in a mapped shared memory segment. A shared memory segment
- is a much larger grain object, creating, destroying and mapping them
- can be much more expensive than creating, destroying or using a
- semaphore and these segments are generally important enough to the
- application to have sensible names. Thus putting a shared memory
- segment in the name space seems reasonable.
-
- For example, a data base library may use a shared member segment named
- /usr/local/lib/dbm/personnel/bufpool to hold the buffer pool for the
- personnel department's data base. The data base library would map
- the buffer pool into each client's address space allowing many data
- base client programs to efficiently access the data base. Each page
- in the buffer pool and each transaction would have its own set of
- semaphores used to synchronize access to the page in the pool or the
- state of a transaction. Giving the buffer pool a name is no problem,
- but giving each semaphore a name is much more of a hassle.
-
- [Aside: Another way of structuring such a data base library is as
- an RPC style multi-threaded server. This allows access to the data
- base from remote machines and allows easier solutions to the security
- and failure problems inherent in the shared memory approach. However
- the shared memory approach has a major performance advantage for systems
- that do not support ultra-fast RPCs. Another approach is to run the
- library in an inner mode. (Unix has one inner mode called the kernel,
- VMS has 3, Multics had many.) This solves the security and failure
- problems of the shared segments but it is generally difficult for mere
- mortals to write their own inner mode libraries.]
-
- One other issue that may cause one to want to unify all objects in
- the file system, at least at the level of using file descriptors to
- refer to all objects if not going so far as to put all objects in the
- name space, is the fact that single threaded programming is much nicer
- if there is a single primitive that will wait for ANY event that the
- process may be interested in (e.g. the 4.2BSD select call.) This call
- is useful if one is to write a single threaded program that doesn't
- busy wait when it has nothing to do but also won't block when an event
- of interest has occurred. With the advent of multi-threaded programming
- the single multi-way wait primitive is no longer needed as instead
- one can create a separate thread each blocking for an event of interest
- and processing it. Multi-way waiting is a problem if single threaded
- programs are going to get maximum use out of the facility.
-
- I've spoken to a number of people in 1003.4 about these ideas. I am
- not sure whether it played any part in their decision.
-
- Just to prove that I am a pro-name space kind of guy, I am currently
- working on and using an experimental file system called Echo that
- integrates the Internet Domain name service for access to global names,
- our internal higher performance name service for highly available
- naming of arbitrary objects, our experimental fault tolerant, log based,
- distributed file service with read/write consistency and universal
- write back for file storage, and auto-mounting NFS for accessing other
- systems.
-
- Objects that are named in our name space currently include:
-
- hosts, users, groups, network servers, network services (a fault
- tolerant network service is generally provided by several servers),
- any every version of any source or object file known by our source
- code control system
-
- Some of these objects are represented in the name space as a directory
- with auxiliary information, mount points or files stored underneath.
- This subsumes much of the use of special files like /etc/passwd,
- /etc/services and the like in traditional Unix. Processes are not
- currently in the name space, but they will/should be. (Just a "simple
- matter of programming.")
-
- For example /-/com/dec/src/user/swart/home/.draft/6.draft is the name
- of the file I am currently typing, /-/com/dec/src/user/swart/shell
- is a symbolic link to my shell, /-/com/dec/prl/perle/nfs/bin/ls is
- the name of the "ls" program on a vanilla Ultrix machine at DEC's Paris
- Research Lab..
-
- [Yes, I know we are using "/-/" as the name of the super root and not
- either "/../" or "//" as POSIX mandates, but those other strings are
- so uhhgly and /../ is especially misleading in a system with multiple
- levels of super root, e.g. on my machine "cd /; pwd" types
- /-/com/dec/src.]
-
- Things that we don't put in the name space are objects that are passed
- within or between processes by 'handle' rather than by name. For
- example, pipes created with the pipe(2) call, need not be in the name
- space. [At a further extreme, pipes for intra-process communication
- don't even involve calling the kernel.]
-
- I personally don't believe in overloading file system operations on
- objects for which the meaning is tenuous (e.g. "unlink" => "kill -TERM"
- on objects of type process); we tend to define new operations for
- manipulating objects of a new type. But that is even more of a
- digression than I wanted to get into!
-
- Sorry for the length of this message, I seem to have gotten carried
- away.
-
- Happy trails,
-
- Garret Swart
- DEC Systems Research Center
- 130 Lytton Avenue
- Palo Alto, CA 94301
- (415) 853-2220
- decwrl!swart.UUCP or swart@src.dec.com
-
- Volume-Number: Volume 21, Number 91
-
- shar.1003.4.m.24121
- echo 1003.4.n
- cat >1003.4.n <<'shar.1003.4.n.24121'
- From std-unix-request@uunet.uu.net Sat Sep 8 10:20:39 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA09766; Sat, 8 Sep 90 10:20:39 -0400
- Posted-Date: 8 Sep 90 00:08:48 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: gumby@Cygnus.COM (David Vinayak Wallace)
- Newsgroups: comp.std.unix
- Subject: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <498@usenix.ORG>
- References: <448@usenix.ORG> <457@usenix.ORG> <488@usenix.ORG> <495@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Organization: Cygnus Support
- X-Submissions: std-unix@uunet.uu.net
- Date: 8 Sep 90 00:08:48 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: gumby@Cygnus.COM (David Vinayak Wallace)
-
- Date: 7 Sep 90 15:23:19 GMT
- From: chip@tct.uucp (Chip Salzenberg)
- [Most of quoted message deleted. -mod]
-
- It is true that other operating systems get along without devices,
- IPC, etc. in their filesystems. That's fine for them; but it's not
- relevant to Unix. Unix programming has a history of relying on the
- filesystem to take care of things that other systems handle as special
- cases -- devices, for example....
-
- What defineds `true Unix?' Don't forget that Multics had all this and
- more in the filesystem; this stuff was REMOVED when Unix was written.
- Is this `continued development by the creators of Unix' just going
- back to what Unix rejected 20 years ago?
-
- Or for a pun for Multics fans: what goes around comes around...
-
- Volume-Number: Volume 21, Number 92
-
- shar.1003.4.n.24121
- echo 1003.4.o
- cat >1003.4.o <<'shar.1003.4.o.24121'
- From std-unix-request@uunet.uu.net Sun Sep 9 01:39:51 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA26843; Sun, 9 Sep 90 01:39:51 -0400
- Posted-Date: 8 Sep 90 15:27:10 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: peter@ficc.ferranti.com (Peter da Silva)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <499@usenix.ORG>
- References: <448@usenix.ORG> <457@usenix.ORG> <488@usenix.ORG> <495@usenix.ORG>
- Sender: std-unix@usenix.ORG
- Reply-To: peter@ficc.ferranti.com (Peter da Silva)
- Organization: Xenix Support, FICC
- X-Submissions: std-unix@uunet.uu.net
- Date: 8 Sep 90 15:27:10 GMT
- To: std-unix@uunet.uu.net
-
- From: peter@ficc.ferranti.com (Peter da Silva)
-
- Other operating systems have learned from UNIX in this respect, in fact!
-
- AmigaOS puts all manner of interesting things in the file name space,
- including pipes (PIPE:name), windows (CON:Left/Top/Width/Height/Title/Flags),
- and the environment (ENV:varname). Other things have been left out but are
- being filled in by users (it's relatively easy to wite device handlers on
- AmigaOS). There are some really odd things like PATH:. This can be opened
- as a file and looks like a list of directory names, or used as a directory
- in which case it looks like the concatenation of all the named directories.
- --
- Peter da Silva. `-_-'
- +1 713 274 5180. 'U`
- peter@ferranti.com
-
- Volume-Number: Volume 21, Number 93
-
- shar.1003.4.o.24121
- echo 1003.4.p
- cat >1003.4.p <<'shar.1003.4.p.24121'
- From std-unix-request@uunet.uu.net Tue Sep 11 14:22:38 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA16709; Tue, 11 Sep 90 14:22:38 -0400
- Posted-Date: 11 Sep 90 03:23:35 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: jfh@rpp386.cactus.org (John F. Haugh II)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <502@usenix.ORG>
- References: <481@usenix.ORG> <495@usenix.ORG> <488@usenix.ORG> <491@usenix.ORG> <493@usenix.ORG> <479@usenix.ORG> <497@usenix.ORG>
- Sender: jsq@usenix.ORG
- Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
- Organization: Lone Star Cafe and BBS Service
- X-Submissions: std-unix@uunet.uu.net
- Date: 11 Sep 90 03:23:35 GMT
- To: std-unix@uunet.uu.net
-
- From: jfh@rpp386.cactus.org (John F. Haugh II)
-
- In article <497@usenix.ORG> swart@src.dec.com (Garret Swart) writes:
- >I believe in putting lots of interesting stuff in the file system name
- >space but I don't believe that semaphores belong there. The reason
- >I don't want to put semaphores in the name space is the same reason
- >I don't want to put my program variables in the name space: I want
- >to have lots of them, I want to create and destroy them very quickly
- >and I want to operate on them even more quickly. In other words, the
- >granularity is wrong.
-
- There is no requirement that you bind every semaphore handle to
- a file system name. Only that the ability to take a semaphore
- handle and create a file system name or take a file system name
- entry and retreive a semaphore handle. This would permit you to
- rapidly create and destroy semaphore for private use, as well as
- provide an external interface for public use.
-
- There is no restriction in either case as to the speed which you
- can perform operations on the handle - file descriptors are
- associated with file system name entries in many cases and I've
- not seen anyone complain that file descriptors slow the system
- down.
- --
- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh
- Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
- "SCCS, the source motel! Programs check in and never check out!"
- -- Ken Thompson
-
- Volume-Number: Volume 21, Number 96
-
- shar.1003.4.p.24121
- echo 1003.4.q
- cat >1003.4.q <<'shar.1003.4.q.24121'
- From std-unix-request@uunet.uu.net Tue Sep 11 14:23:32 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA16907; Tue, 11 Sep 90 14:23:32 -0400
- Posted-Date: 11 Sep 90 07:06:23 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <503@usenix.ORG>
- References: <481@usenix.ORG> <495@usenix.ORG> <488@usenix.ORG> <491@usenix.ORG> <497@usenix.ORG> <497@usenix.ORG>,
- Sender: jsq@usenix.ORG
- Organization: Comp Sci, RMIT, Melbourne, Australia
- X-Submissions: std-unix@uunet.uu.net
- Date: 11 Sep 90 07:06:23 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)
-
- In article <497@usenix.ORG>, swart@src.dec.com (Garret Swart) writes:
- > I believe in putting lots of interesting stuff in the file system name
- > space but I don't believe that semaphores belong there. The reason
- > I don't want to put semaphores in the name space is the same reason
- > I don't want to put my program variables in the name space: I want
- > to have lots of them, I want to create and destroy them very quickly
- > and I want to operate on them even more quickly. In other words, the
- > granularity is wrong.
-
- So why not choose a different granularity? Have the thing that goes in
- the file system name space be an (extensible) *array* of semaphores.
- To specify a semaphore, one would use a (descriptor, index) pair.
- To create a semaphore in a semaphore group, just use it.
- If you want to have a semaphore associated with a data structure in
- mapped memory, just use a lock on the appropriate byte range of the
- mapped file.
-
- (Am I hopelessly confused, or aren't advisory record locks *already*
- equivalent to binary semaphores? Trying to lock a range of bytes in
- a file is just a multi-wait, no? Why do we need two interfaces? (I
- can see that two or more _implementations_ behind the interface might
- be a good idea, but that's another question.)
- --
- Heuer's Law: Any feature is a bug unless it can be turned off.
-
- Volume-Number: Volume 21, Number 97
-
- shar.1003.4.q.24121
- echo 1003.4.r
- cat >1003.4.r <<'shar.1003.4.r.24121'
- From std-unix-request@uunet.uu.net Wed Sep 12 17:26:34 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA19542; Wed, 12 Sep 90 17:26:34 -0400
- Posted-Date: 12 Sep 90 16:35:12 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: tct!chip@cs.utexas.edu (Chip Salzenberg)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <508@usenix.ORG>
- References: <488@usenix.ORG> <495@usenix.ORG> <498@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: Teltronics/TCT, Sarasota, FL
- X-Submissions: std-unix@uunet.uu.net
- Date: 12 Sep 90 16:35:12 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: chip@tct.uucp (Chip Salzenberg)
-
- According to gumby@Cygnus.COM (David Vinayak Wallace):
- >Is this `continued development by the creators of Unix' just going
- >back to what Unix rejected 20 years ago?
-
- They threw away what wouldn't fit. Then they added features, but
- piece by piece, and only as they observed a need.
-
- This cycle has started again with Plan 9, which borrows heavily from
- Unix -- almost everything lives in the filesystem -- but which is in
- fact a brand new start.
-
- Unix owes much to Multics, and we can learn from it, but we needn't be
- driven by it.
- --
- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
-
- Volume-Number: Volume 21, Number 102
-
- shar.1003.4.r.24121
- echo 1003.4.s
- cat >1003.4.s <<'shar.1003.4.s.24121'
- From std-unix-request@uunet.uu.net Mon Sep 17 20:27:05 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA27220; Mon, 17 Sep 90 20:27:05 -0400
- Posted-Date: 17 Sep 90 21:02:49 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: fouts@bozeman.bozeman.ingr (Martin Fouts)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <523@usenix.ORG>
- References: <448@usenix.ORG> <457@usenix.ORG> <488@usenix.ORG> <495@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: INTERGRAPH (APD) -- Palo Alto, CA
- X-Submissions: std-unix@uunet.uu.net
- Date: 17 Sep 90 21:02:49 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: fouts@bozeman.bozeman.ingr (Martin Fouts)
-
- >>>>> On 7 Sep 90 15:23:19 GMT, chip@tct.uucp (Chip Salzenberg) said:
-
- Chip> According to fouts@bozeman.bozeman.ingr (Martin Fouts):
- >I'm not sure which Unix you've been running for the past five or more
- >years, but a lot of stuff doesn't live in the file system name space ...
-
- Chip> The absense of sockets (except UNIX domain), System V IPC, etc. from
- Chip> the file system is, in the opinion of many, a bug. It is a result of
- Chip> Unix being extended by people who do not understand Unix.
- ^-------------------------------^
-
- My aren't we superior. (;-) At one time, I believed that sockets
- belonged in the filesystem name space. I spent a long time arguing
- this point with members of the networking community before they
- convinced me that certain transient objects do not belong in that name
- space. (See below)
-
- Chip> Research Unix, which is the result of continued development by the
- Chip> creators of Unix, did not take things out of the filesystem. To the
- Chip> contrary, it put *more* things there, including processes (via the
- Chip> /proc pseudo-directory).
-
- The value of proc in the file system are debatable. Certain debugging
- tools are easier to hang on an fcntl certain others are not. However, the
- presences of the proc file system is not a strong arguement for the
- inclusion of othere features in the file system.
-
- Chip> It is true that other operating systems get along without devices,
- Chip> IPC, etc. in their filesystems. That's fine for them; but it's not
- Chip> relevant to Unix. Unix programming has a history of relying on the
- Chip> filesystem to take care of things that other systems handle as special
- Chip> cases -- devices, for example. The idea that devices can be files but
- Chip> TCP/IP sockets cannot runs counter to all Unix experience.
-
- Unix programming has a history of using the filesystem for some things
- and not using it for others. For example, I can demonstrate a
- semantic under which it is possible to put the time of day clock into
- the file system and reference it by opening the i.e. /dev/timeofday
- file. Each time I read from that file, I would get the current time.
- Via fcntls, I could extend this to handle timer functions. It wasn't
- done in Unix. (I've done similar things in other OSs I've designed,
- though.)
-
- The whole point of the response which you partially quoted was to
- remind the poster I was responding to that not all functions which
- might have been placed in the filesystem automatically have.
-
- Chip> The reason why I continue this discussion here, in comp.std.unix, is
- Chip> that many Unix programmers hope that the people in the standardization
- Chip> committees have learned from the out-of-filesystem mistake, and will
- Chip> rectify it.
- Chip> --
-
- The reason I respond is that it is not automatically safe to assume
- that something belongs in the file system because something else is
- already there. There is also an explicit problem not mentioned in
- this discussion which is the distinction between filesystem name space
- and filesystem semantics. Sometimes there are objects which would be
- reasonable to treat with filesystem semantics for which there is no
- reasonable mechanism for introducing them into the filesystem name
- space. Because of the way network connections are made, I have been
- convinced by networking experts (who are familiar with the "Unix
- style") that the filesystem namespace does not have a good semantic
- match for the network name space.
-
- Chip> Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
-
- Chip> Volume-Number: Volume 21, Number 89
-
- Marty
- --
- Martin Fouts
-
- UUCP: ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
- ARPA: apd!fouts@ingr.com
- PHONE: (415) 852-2310 FAX: (415) 856-9224
- MAIL: 2400 Geng Road, Palo Alto, CA, 94303
-
- Moving to Montana; Goin' to be a Dental Floss Tycoon.
- - Frank Zappa
-
- Volume-Number: Volume 21, Number 114
-
- shar.1003.4.s.24121
- echo 1003.4.t
- cat >1003.4.t <<'shar.1003.4.t.24121'
- From std-unix-request@uunet.uu.net Tue Sep 18 18:19:33 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA25986; Tue, 18 Sep 90 18:19:33 -0400
- Posted-Date: 18 Sep 90 20:03:32 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <524@usenix.ORG>
- References: <488@usenix.ORG> <495@usenix.ORG> <523@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: IR
- X-Submissions: std-unix@uunet.uu.net
- Date: 18 Sep 90 20:03:32 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
-
- In article <523@usenix.ORG> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
- > At one time, I believed that sockets
- > belonged in the filesystem name space. I spent a long time arguing
- > this point with members of the networking community before theyy
- > convinced me that certain transient objects do not belong in that name
- > space.
-
- In contrast, I've found it quite easy to get people to agree that
- practically every object should be usable as an open *file*. The beauty
- and power of UNIX is the abstraction of files---not filesystems. I'd say
- that the concept of an open file descriptor is one of the most important
- reasons that UNIX-style operating systems are taking over the world.
-
- chip@tct.uucp (Chip Salzenberg) writes:
- > The reason why I continue this discussion here, in comp.std.unix, is
- > that many Unix programmers hope that the people in the standardization
- > committees have learned from the out-of-filesystem mistake, and will
- > rectify it.
-
- I am a UNIX programmer who strongly hopes that standards committees will
- never make the mistake of putting network objects into the filesystem.
- Although the semantics of read() and write() fit network connections
- perfectly, the semantics of open() most certainly do not. I will readily
- support passing network connections as file descriptors. I will fight
- tooth and nail to make sure that they need not be passed as filenames.
-
- ---Dan
-
- Volume-Number: Volume 21, Number 115
-
- shar.1003.4.t.24121
- echo 1003.4.u
- cat >1003.4.u <<'shar.1003.4.u.24121'
- From std-unix-request@uunet.uu.net Thu Sep 20 14:19:56 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA10651; Thu, 20 Sep 90 14:19:56 -0400
- Posted-Date: 20 Sep 90 12:53:46 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: tct!chip@cs.utexas.edu (Chip Salzenberg)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <528@usenix.ORG>
- References: <495@usenix.ORG> <523@usenix.ORG> <524@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: Teltronics/TCT, Sarasota, FL
- X-Submissions: std-unix@uunet.uu.net
- Date: 20 Sep 90 12:53:46 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: chip@tct.uucp (Chip Salzenberg)
-
- According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
- >The beauty and power of UNIX is the abstraction of files---
- >not filesystems.
-
- The filesystem means that anything worth reading or writing can be
- accessed by a name in one large hierarchy. It means a consistent
- naming scheme. It means that any entity can be opened, listed,
- renamed or removed.
-
- Both the filesystem and the file descriptor are powerful abstractions.
- Do not make the mistake of minimizing either one's contribution to the
- power and beauty of UNIX.
- --
- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
-
- Volume-Number: Volume 21, Number 118
-
- shar.1003.4.u.24121
- echo 1003.4.v
- cat >1003.4.v <<'shar.1003.4.v.24121'
- From std-unix-request@uunet.uu.net Thu Sep 20 14:20:46 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA10926; Thu, 20 Sep 90 14:20:46 -0400
- Posted-Date: 20 Sep 90 12:48:04 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: tct!chip@cs.utexas.edu (Chip Salzenberg)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <529@usenix.ORG>
- References: <488@usenix.ORG> <495@usenix.ORG> <523@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: Teltronics/TCT, Sarasota, FL
- X-Submissions: std-unix@uunet.uu.net
- Date: 20 Sep 90 12:48:04 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: chip@tct.uucp (Chip Salzenberg)
-
- According to fouts@bozeman.bozeman.ingr (Martin Fouts):
- >According to chip@tct.uucp (Chip Salzenberg):
- >> Research Unix [...] put *more things [in the filesystem],
- >> including processes (via the /proc pseudo-directory).
- >
- >The value of proc in the file system are debatable. Certain debugging
- >tools are easier to hang on an fcntl certain others are not.
-
- With /proc, some things are much easier. (Getting a list of all
- active pids, for example.) Nothing, however, is harder. A big win.
-
- >However, the presences of the proc file system is not a strong arguement
- >for the inclusion of othere features in the file system.
-
- I disagree. I consider it an excellent example of how the designers
- of Unix realize that all named objects potentially visible to more
- than one process belong in the filesystem namespace.
-
- >Unix programming has a history of using the filesystem for some things
- >and not using it for others. For example, I can demonstrate a
- >semantic under which it is possible to put the time of day clock into
- >the file system ...
-
- Of course. But in the absense of remotely mounted filesystems --
- which V7 Unix was not designed to support -- there is only one time of
- day, so it needs no name. (I wouldn't be surprised if Plan 9 has a
- /dev/timeofday, however.)
-
- >... not all functions which might have been placed in the
- >filesystem automatically have.
-
- This observation is correct. But it is clear that the designers of
- Research Unix have used the filesystem for everything that needs a
- name, and they continue to do so. Their work asks, "Why have multiple
- namespaces?" Plan 9 asks the question again, and with a megaphone.
-
- >Because of the way network connections are made, I have been
- >convinced by networking experts (who are familiar with the "Unix
- >style") that the filesystem namespace does not have a good semantic
- >match for the network name space.
-
- Carried to its logical conclusion, this argument would invalidate
- special files and named pipes, since they also lack a "good semantic
- match" with flat files. In fact, the only entities with a "good
- semantic match" for flat files are -- you guessed it -- flat files.
-
- So, how do we program in such a system? We use its elegant interface
- -- or should I say "interfaces"? Plain files, devices, IPCs, and
- network connections each have a semantically accurate interface, which
- unfortunately makes it different from all others.
-
- This is progress? "Forward into the past!"
- --
- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
-
- Volume-Number: Volume 21, Number 119
-
- shar.1003.4.v.24121
- echo 1003.4.w
- cat >1003.4.w <<'shar.1003.4.w.24121'
- From std-unix-request@uunet.uu.net Sun Sep 23 19:28:32 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA24302; Sun, 23 Sep 90 19:28:32 -0400
- Posted-Date: 23 Sep 90 15:48:18 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: peter@ficc.ferranti.com (Peter da Silva)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <539@usenix.ORG>
- References: <448@usenix.ORG> <457@usenix.ORG> <488@usenix.ORG> <495@usenix.ORG> <523@usenix.ORG>
- Sender: jsq@usenix.ORG
- Reply-To: peter@ficc.ferranti.com (Peter da Silva)
- Organization: Xenix Support, FICC
- X-Submissions: std-unix@uunet.uu.net
- Date: 23 Sep 90 15:48:18 GMT
- To: std-unix@uunet.uu.net
-
- Submitted-by: peter@ficc.ferranti.com (Peter da Silva)
-
- In article <523@usenix.ORG> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
- > My aren't we superior. (;-) At one time, I believed that sockets
- > belonged in the filesystem name space. I spent a long time arguing
- > this point with members of the networking community before they
- > convinced me that certain transient objects do not belong in that name
- > space. (See below)
-
- You mean things that don't operate like a single bidirectional stream, like
- pipes? It's funny that the sockets that *do* behave that way are not in the
- file system, while UNIX-domain sockets (which have two ends on the local box)
- are.
-
- > Unix programming has a history of using the filesystem for some things
- > and not using it for others.
-
- UNIX programming has a history of using whatever ad-hoc hacks were needed
- to get things working. It's full of evolutionary dead-ends... some of which
- have been discarded (multiplexed files) and some of which have been patched
- up and overloaded (file protection bits). But where things have moved closer
- to the underlying principles (everything is a file, for example) it's become
- the better for it.
-
- > Sometimes there are objects which would be
- > reasonable to treat with filesystem semantics for which there is no
- > reasonable mechanism for introducing them into the filesystem name
- > space.
-
- This seems reasonable, but the rest is a pure argument from authority.
- Could you repeat these arguments for the benefit of hose of us who don't
- have the good fortune to know these networking experts you speak of?
-
- [ Everyone involved in this discussion, please try to keep it in a
- technical, not a personal, vein. -mod ]
-
- --
- Peter da Silva. `-_-'
- +1 713 274 5180. 'U`
- peter@ferranti.com
-
- Volume-Number: Volume 21, Number 127
-
- shar.1003.4.w.24121
- echo 1003.4.x
- cat >1003.4.x <<'shar.1003.4.x.24121'
- From std-unix-request@uunet.uu.net Tue Sep 25 10:37:08 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA00719; Tue, 25 Sep 90 10:37:08 -0400
- Posted-Date: 24 Sep 90 21:30:35 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <540@usenix.ORG>
- References: <523@usenix.ORG> <524@usenix.ORG> <528@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: IR
- X-Submissions: std-unix@uunet.uu.net
- Date: 24 Sep 90 21:30:35 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
-
- In article <528@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
- > According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
- > >The beauty and power of UNIX is the abstraction of files---
- > >not filesystems.
- > Both the filesystem and the file descriptor are powerful abstractions.
-
- On the contrary: Given file descriptors, the filesystem is an almost
- useless abstraction.
-
- Programs fall into two main classes. Some (such as diff) take a small,
- fixed number of filename arguments and treat each one specially. They
- become both simpler and more flexible if they instead use file
- descriptors. I'll propose multitee as an example of this.
-
- Others (such as sed or compress) take many filenames and perform some
- action on each file in turn. They also become both simpler and more
- flexible if they instead take input and output from a couple of file
- descriptors, perhaps with a simple protocol for indicating file
- boundaries. I'll propose the new version of filterfile as a
- demonstration of how this can simplify application development.
-
- In both cases, the application need know absolutely nothing about the
- filesystem. A few utilities deal with filenames---shell redirection and
- cat. A few utilities do the same for network connections---authtcp and
- attachport. A few utilities do the same for pipes---the shell's piping.
- But beyond these two or three programs per I/O object, the filesystem
- contributes *nothing* to the vast majority of applications.
-
- There is one notable exception. Some programs depend on reliable,
- static, local or virtually local storage, usually for what amounts to
- interprocess communication. (login needs /etc/passwd. cron reads crontab.
- And so on.) This is exactly what filesystems were designed for, and a
- program that wants reliable, static, local storage is perfectly within
- its rights to demand the sensible abstraction we call a filesystem.
-
- Most applications that use input and output, though, don't care that
- it's reliable or static or local. For them, the filesystem is pointless.
- Many of us are convinced that open() and rename() and unlink() and so on
- are an extremely poor match for unreliable or dynamic or remote I/O. We
- also see the sheer uselessness of forcing all I/O into the filesystem.
- You must convince us that open() makes sense for everything that might
- be a file descriptor, and that it provides a real benefit for future
- applications, before you destroy what we see as the beauty and power of
- UNIX.
-
- ---Dan
-
- Volume-Number: Volume 21, Number 128
-
- shar.1003.4.x.24121
- echo 1003.4.y
- cat >1003.4.y <<'shar.1003.4.y.24121'
- From std-unix-request@uunet.uu.net Tue Sep 25 10:20:43 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA24327; Tue, 25 Sep 90 10:20:43 -0400
- Posted-Date: 24 Sep 90 21:40:07 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <541@usenix.ORG>
- References: <495@usenix.ORG> <523@usenix.ORG> <539@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: IR
- X-Submissions: std-unix@uunet.uu.net
- Date: 24 Sep 90 21:40:07 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
-
- In article <539@usenix.ORG> peter@ficc.ferranti.com (Peter da Silva) writes:
- > But where things have moved closer
- > to the underlying principles (everything is a file, for example) it's become
- > the better for it.
-
- The underlying principle is that everything is a file *descriptor*.
-
- > > Sometimes there are objects which would be
- > > reasonable to treat with filesystem semantics for which there is no
- > > reasonable mechanism for introducing them into the filesystem name
- > > space.
- > This seems reasonable, but the rest is a pure argument from authority.
- > Could you repeat these arguments for the benefit of hose of us who don't
- > have the good fortune to know these networking experts you speak of?
-
- The filesystem fails to deal with many (most?) types of I/O that aren't
- reliable, static, and local. Here's an example: In reality, you initiate
- a network stream connection in two stages. First you send off a request,
- which wends its way through the network. *Some time later*, the response
- arrives. Even if you aren't doing a three-way handshake, you must wait a
- long time (in practice, up to several seconds on the Internet) before
- you know whether the open succeeds.
-
- In the filesystem abstraction, you open a filename in one stage. You
- can't do anything between initiating the open and finding out whether or
- not it succeeds. This just doesn't match reality, and it places a huge
- restriction on programs that want to do something else while they
- communicate.
-
- You can easily construct other examples, but one should be enough to
- convince you that open() just isn't sufficiently general for everything
- that you might read() or write().
-
- ---Dan
-
- Volume-Number: Volume 21, Number 129
-
- shar.1003.4.y.24121
- echo 1003.4.z
- cat >1003.4.z <<'shar.1003.4.z.24121'
- From std-unix-request@uunet.uu.net Tue Sep 25 16:34:14 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA16616; Tue, 25 Sep 90 16:34:14 -0400
- Posted-Date: 25 Sep 90 16:44:28 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: henry@zoo.toronto.edu (Henry Spencer)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
- Message-Id: <543@usenix.ORG>
- References: <495@usenix.ORG> <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: U of Toronto Zoology
- X-Submissions: std-unix@uunet.uu.net
- Date: 25 Sep 90 16:44:28 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
-
- In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
- >In the filesystem abstraction, you open a filename in one stage. You
- >can't do anything between initiating the open and finding out whether or
- >not it succeeds. This just doesn't match reality, and it places a huge
- >restriction on programs that want to do something else while they
- >communicate.
-
- Programs that want to do two things at once should use explicit parallelism,
- e.g. some sort of threads facility. In every case I've seen, this yielded
- vastly superior code, with clearer structure and better error handling.
- --
- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
- OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
-
- Volume-Number: Volume 21, Number 131
-
- shar.1003.4.z.24121
- echo 1003.5.a
- cat >1003.5.a <<'shar.1003.5.a.24121'
- From std-unix-request@uunet.uu.net Mon Sep 17 20:25:12 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA26016; Mon, 17 Sep 90 20:25:12 -0400
- Posted-Date: 17 Sep 90 19:58:52 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, IEEE 1003.5: Ada bindings
- Message-Id: <522@usenix.ORG>
- References: <521@usenix.ORG>
- Sender: jsq@usenix.ORG
- Reply-To: randall@Virginia.EDU (Ran Atkinson)
- Organization: University of Virginia
- X-Submissions: std-unix@uunet.uu.net
- Date: 17 Sep 90 19:58:52 GMT
- To: std-unix@uunet.uu.net
-
- Submitted-by: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
-
- The comment in the snitch report about the committee "knowing" that
- 30 days being insufficient time to review the P1003.5 draft is distressing.
-
- Indeed I am one of the folks who is going to try to review the draft and
- 30 days is no where near enough time to do a proper job. The notion of
- starting at different places is NOT helpful because it is likely that my
- objections won't be evenly distributed across the document and because any
- I miss for lack of time can't be raised in a future ballot.
-
- The TCOS administration should REQUIRE that balloting groups be given
- sufficient time to review documents thoroughly. Otherwise we will end
- up with incompletely reviewed standards which we will then have to try
- to live with.
-
- This just serves to reinforce my view that the POSIX effort has changed
- from standardising existing practice with due deliberation to one to
- create as many standards documents as possible as quickly as possible
- without due regard for existing practice or internal consistency among
- the various documents that are under P1003.
-
- Standards are a good thing if done carefully. I'm concerned that the
- POSIX effort is moving too hastily to be truly useful to us users.
-
- Randall Atkinson
- randall@Virginia.EDU
-
- Volume-Number: Volume 21, Number 113
-
- shar.1003.5.a.24121
- echo 1003.5.b
- cat >1003.5.b <<'shar.1003.5.b.24121'
- From std-unix-request@uunet.uu.net Wed Sep 19 18:25:12 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA24407; Wed, 19 Sep 90 18:25:12 -0400
- Posted-Date: 19 Sep 90 17:09:18 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: arnold%audiofax.com@mathcs.emory.edu (Arnold Robbins)
- Newsgroups: comp.std.unix
- Subject: Balloting times (was: Re: Standards Update, IEEE 1003.5: Ada bindings)
- Message-Id: <526@usenix.ORG>
- References: <521@usenix.ORG> <522@usenix.ORG>
- Sender: jsq@usenix.ORG
- Reply-To: arnold@audiofax.com
- Organization: AudioFAX Inc., Atlanta
- X-Submissions: std-unix@uunet.uu.net
- Date: 19 Sep 90 17:09:18 GMT
- To: std-unix@uunet.uu.net
-
- Submitted-by: arnold%audiofax.com@mathcs.emory.edu (Arnold Robbins)
-
- In article <522@usenix.ORG> randall@Virginia.EDU (Ran Atkinson) writes:
- >Indeed I am one of the folks who is going to try to review the draft and
- >30 days is no where near enough time to do a proper job.
-
- Let me second this with a very loud, resounding "Amen!". The 1003.2 drafts
- are *huge*. A month to go through them is just silly. I did a lousy job
- on the last one, just because of a lack of time.
- --
- Arnold Robbins AudioFAX, Inc. | Laundry increases
- 2000 Powers Ferry Road, #200 / Marietta, GA. 30067 | exponentially in the
- INTERNET: arnold@audiofax.com Phone: +1 404 933 7600 | number of children.
- UUCP: emory!audfax!arnold Fax-box: +1 404 618 4581 | -- Miriam Robbins
-
- Volume-Number: Volume 21, Number 117
-
- shar.1003.5.b.24121
- echo bof.a
- cat >bof.a <<'shar.bof.a.24121'
- From std-unix-request@uunet.uu.net Thu Aug 23 15:19:23 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA29203; Thu, 23 Aug 90 15:19:23 -0400
- Posted-Date: 22 Aug 90 00:17:46 GMT
- Received: by cs.utexas.edu (5.64/1.71)
- id AA22661; Thu, 23 Aug 90 14:19:19 -0500
- From: calvin!sws@cs.utexas.edu (Susanne Smith)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, USENIX Standards BOF
- Message-Id: <454@usenix.ORG>
- References: <434@usenix.ORG>
- Sender: std-unix@usenix.ORG
- X-Submissions: std-unix@uunet.uu.net
- Date: 22 Aug 90 00:17:46 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- From: sws@calvin.uucp (Susanne Smith)
-
- >2. Opinion polling
- >
- > John tried to discern whether attendees thought they were being
- > well-served by John, the USENIX Standards Watchdog Committee,
- > and the USENIX position on standards: to attempt to prevent
- > standards from prohibiting innovation. Indeed, at Snowbird, the
- > site of the April POSIX meeting, John was told that smaller
- > companies don't like our participation because of this position.
- > Think about this a while. (For a more detailed discussion of
- > the USENIX position on standards, see either ;login: 15(3):25 or
- > the periodic overview posting in comp.std.unix about the USENIX
- > Standards Watchdog Committee.)
- >
- > John explained how USENIX came to its current policies and why
- > it does not endorse standards of its own. Some audience members
- > were unhappy with extant standards bodies and said they wouldn't
- > mind if USENIX played a more active role. Susanne reminded us
- > that UniForum working groups, which she praised, play such a
- > role.
-
- What I remember about this portion of the bof is a little bit different.
- John had been talking about the new procedures developed by the TCOS
- (IEEE Computer Society Technical Committee on Operating Systems)
- SEC (Standards Executive Committee) to limit the proliferation of
- standards groups and to make sure that groups in existence
- made acceptable progress (see Volume 19, Number 97). The question was
- asked as to what other forums are available for groups that do not gain
- SEC approval. The UniForum Technical Committees were mentioned as one
- forum for work that might be premature or inappropriate for TCOS.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Volume-Number: Volume 21, Number 55
-
- shar.bof.a.24121
- echo nist.a
- cat >nist.a <<'shar.nist.a.24121'
- From std-unix-request@uunet.uu.net Fri Sep 28 21:22:12 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA03871; Fri, 28 Sep 90 21:22:12 -0400
- Posted-Date: 28 Sep 90 19:27:10 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: gwyn@smoke.brl.mil (Doug Gwyn)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
- Message-Id: <560@usenix.ORG>
- References: <558@usenix.ORG>
- Sender: jsq@usenix.ORG
- Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
- X-Submissions: std-unix@uunet.uu.net
- Date: 28 Sep 90 19:27:10 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
-
- In article <558@usenix.ORG> std-unix@uunet.uu.net writes:
- >Standards let the government avoid vendor-specific requirements like
- >UNIX or SVID. ...
- >The Government has a burning need for a standard, they find it
- >politically unacceptable to use UNIX System V as that standard, ...
-
- I have to challenge this often-heard (from DEC, for example, who don't
- want truly open systems in the first place) rationale. In fact there
- have been more than one major (in the billion-dollar range) federal
- acquisition where SVID conformance was specified, and that specification
- was successfully upheld in appeals. Thus the government's official
- position would appear to be that SVID is an acceptable standard.
-
- Note that SVID is not the same as AT&T UNIX System V implementation,
- although there is clearly a relationship between them. (But there
- also is between UNIX System V and POSIX, ANSI C, etc.)
-
- Volume-Number: Volume 21, Number 148
-
- shar.nist.a.24121
- echo nist.b
- cat >nist.b <<'shar.nist.b.24121'
- From std-unix-request@uunet.uu.net Fri Sep 28 21:22:20 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA03945; Fri, 28 Sep 90 21:22:20 -0400
- Posted-Date: 28 Sep 90 23:49:05 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
- Message-Id: <561@usenix.ORG>
- References: <558@usenix.ORG>
- Sender: jsq@usenix.ORG
- Reply-To: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
- Organization: University of Virginia
- X-Submissions: std-unix@uunet.uu.net
- Date: 28 Sep 90 23:49:05 GMT
- To: std-unix@uunet.uu.net
-
- Submitted-by: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
-
- As a former Federal employee and someone who looks at POSIX
- strictly from the user point of view, I'd much rather see NIST
- write a FIPS based on P1003.2/10 AND the current P1003.2a than
- to have them write one based on P1003.2/9 because it seems clear
- that draft 9 will be farther from the end product than draft 10
- will be by a significant margin and P1003.2a has a lot of stuff
- that most existing UNIX (tm) users expect to see that was omitted
- from P1003.2. For that matter, it might be worth looking at the
- SVID for System V, Release 4 and the BSD 4.3 Tahoe documentation
- to see if there is other stuff that isn't part of the P1003.2
- effort that NIST thinks government users need. For my part,
- I want P1003.2 to specify an environment with capabilties
- comparable to what BSD and the SVID both specify and I don't
- really see that just now in the drafts.
-
- I have mixed feelings about the notion of NIST pushing the FIPS this fast,
- but I agree that some vendors are clearly just trying to drag out the
- IEEE standards process and are trying to water down the standard so
- that their existing proprietary system will meet the standard.
-
- Randall Atkinson
- randall@Virginia.EDU
-
- Volume-Number: Volume 21, Number 149
-
- shar.nist.b.24121
- echo nist.c
- cat >nist.c <<'shar.nist.c.24121'
- From std-unix-request@uunet.uu.net Mon Oct 1 14:33:19 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA03094; Mon, 1 Oct 90 14:33:19 -0400
- Posted-Date: 1 Oct 90 15:50:25 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: vyw@stc06.ctd.ornl.gov (WHITE V L)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
- Message-Id: <567@usenix.ORG>
- Sender: jsq@usenix.ORG
- Subject-References: <558@usenix.ORG> <560@usenix.ORG>
- X-Submissions: std-unix@uunet.uu.net
- Date: 1 Oct 90 15:50:25 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: vyw@stc06.ctd.ornl.gov (WHITE V L)
-
- Doug Gwyn writes:
-
- >In article <558@usenix.ORG> std-unix@uunet.uu.net writes:
- >>Standards let the government avoid vendor-specific requirements like
- >>UNIX or SVID. ...
- >>The Government has a burning need for a standard, they find it
- >>politically unacceptable to use UNIX System V as that standard, ...
- >
- >I have to challenge this often-heard (from DEC, for example, who don't
- >want truly open systems in the first place) rationale. In fact there
- >have been more than one major (in the billion-dollar range) federal
- >acquisition where SVID conformance was specified, and that specification
- >was successfully upheld in appeals. Thus the government's official
- >position would appear to be that SVID is an acceptable standard.
-
- Yes and no. This is hard to explain to someone who hasn't lived through it.
- Yes, the 3.5 billion dollar AFCAC case upheld the legality of the use of
- the SVID in procurements. No, SVID is not proprietary and any vendor
- who wished could make his system conform to it. Yes, the SVID is a perfectly
- good standard and we could be using it to fill in the gaps in our
- procurement specs until the IEEE has time to produce a reasonable and
- mature set of Posix standards.
-
- So why aren't we?
-
- One reason is that we don't want to lock out systems that are primarily
- Berkeley based. However, we could still pull out enough definitions from
- the SVID for utilities which don't differ any or much from their BSD
- equivalents, write out exceptions to allow for the BSD differences,
- and have a decent spec which would get us a Unix (not a proprietary) system.
-
- The bigger reason is that "SVID" is a four letter word to the federal
- supervisors who are pressured by vendors hinting darkly at protests.
- The AFCAC precedent doesn't stop these threats, and it doesn't matter whether
- the vendor could actually win one of these protests.
- Any protest, whether it is eventually upheld or not, adds an incredible
- burden of time, money, and headaches to the already baroque procurement
- process. It can stop your buy for months. The problem is
- the vendors who have had a free reign in the government for so many years and
- aren't willing to give up their hold now that
- they are being forced to play by the rules of competitive procurement.
- I suppose the problem is also the system that lets them clog the works with
- unjustified protests, but I don't know how to prevent that without being
- unfair to the vendors who have justified protests.
-
- I've been told this is no excuse to pressure the longsuffering Roger Martin
- to hurry through an immature FIPS and that I should just write a better spec,
- good grief. Just say what I want. That's my job, after all.
- Well, I have done that, because I had to, and I ask you, how am I
- to define what shell or editor or grep I want without reference to
- SVID or the BSD manual or X/OPEN or some draft of 1003.2 (to which I am
- reminded on every page not to require conformance)? Somebody has a complaint
- about all of them, and I've wasted a lot of time bending words to satisfy
- nervous bosses when I'd rather be programming.
-
- Yes, we should make the standards process reasonable and not rush it.
- Yes, we'll have to make some sacrifices in lost productivity in the meantime
- in order to accomplish that goal. It would help a lot if the vendors
- meant what they said about their standards support instead of standing
- in the way. And you know, I've used the products of those vendors who
- are making the most noise, and they're GOOD. Don't they believe that
- themselves? Don't they think their products can stand on their own merits?
- Why are they so afraid of the big bad SVID?
-
- I'm sorry this is a nontechnical contribution, and a long one at that,
- but unfortunately the
- nontechnical problems sometimes have a greater impact on our work and
- are more difficult to overcome than the technical ones.
-
- These opinions are wholely mine and do not represent an official position
- of my employers or of the federal government.
-
- Vicky White
- Oak Ridge National Laboratory
- vyw@ornl.gov
-
- Volume-Number: Volume 21, Number 159
-
- shar.nist.c.24121
- echo nist.d
- cat >nist.d <<'shar.nist.d.24121'
- From std-unix-request@uunet.uu.net Mon Oct 1 14:30:23 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA01767; Mon, 1 Oct 90 14:30:23 -0400
- Posted-Date: 1 Oct 90 17:56:00 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: hl.rogers@ncrcae.Columbia.NCR.COM (HL Rogers)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
- Message-Id: <107019@uunet.UU.NET>
- References: <558@usenix.ORG>
- Sender: jsq@uunet.uu.net
- Reply-To: hl.rogers@ncrcae.Columbia.NCR.COM (HL Rogers)
- Organization: NCR E&M Columbia, Columbia, SC
- X-Submissions: std-unix@uunet.uu.net
- Date: 1 Oct 90 17:56:00 GMT
- To: std-unix@uunet.uu.net
-
- Submitted-by: rogers@ofc.uucp
-
- In article <558@usenix.ORG> std-unix@uunet.uu.net writes:
- >
- >In my opinion, NIST is going to go ahead and publish a flawed FIPS in
- >the belief that it will drive the IEEE to pick up the pace of POSIX.
- >The Government has a burning need for a standard, they find it
- >politically unacceptable to use UNIX System V as that standard, and
- >they strongly prefer action over waiting for the IEEE.
- >
- There is something to be said for any action which motivates the IEEE
- committees to move a little faster. This type of action, however, will
- ultimately cost the taxpayer when agencies who purchase D9 implementations
- have to retool a year later because all the developed applications will
- honor the final dot 2 draft.
-
- What I fail to understand is IEEE's continuing propensity to violate the
- "prime directive", i.e., their failure to specify common practice. As
- long as they continue this annoying habit, they will continue creating
- these problems. It is far better to specify common practice, then work
- through some other forum on getting the vendors to change the functionality
- for future versions.
-
- Attempting to legislate change through IEEE dot n committees may even
- work, but guess what? Instead of Uncle Sam buying something off the
- shelf for near commodity prices, he has to buy a "special" for inflated
- prices because it had to be especially developed. Nobody had it, not
- common practice,... And guess what else? You, I, Roger Martin, and
- the rest of us collectively make up "Uncle Sam." It's your money, ace.
-
- IMHO, IEEE "management" needs to put their foot down and put an end to
- the real political battles - those being fought in IEEE dot n
- committees. Then NIST would be an ally instead of an opponent.
- ---
- HL Rogers (hl.rogers@ncrcae.Columbia.NCR.COM)
-
- Volume-Number: Volume 21, Number 160
-
- shar.nist.d.24121
- echo nist.e
- cat >nist.e <<'shar.nist.e.24121'
- From jsq@cs.utexas.edu Wed Oct 3 08:58:59 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA02719; Wed, 3 Oct 90 08:58:59 -0400
- Posted-Date: 3 Oct 90 10:06:10 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: domo@tsa.co.uk (Dominic Dunlop)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
- Message-Id: <13137@cs.utexas.edu>
- References: <558@usenix.ORG> <107019@uunet.UU.NET>
- Sender: jsq@cs.utexas.edu
- Reply-To: domo@tsa.co.uk
- Organization: The Standard Answer Ltd.
- X-Submissions: std-unix@uunet.uu.net
- Date: 3 Oct 90 10:06:10 GMT
- To: std-unix@uunet.uu.net
-
- Submitted-by: domo@tsa.co.uk (Dominic Dunlop)
-
- In article <107019@uunet.UU.NET> hl.rogers@ncrcae.Columbia.NCR.COM
- (HL Rogers) writes:
- > There is something to be said for any action which motivates the IEEE
- > committees to move a little faster. This type of action, however, will
- > ultimately cost the taxpayer when agencies who purchase D9 implementations
- > have to retool a year later because all the developed applications will
- > honor the final dot 2 draft.
-
- While we can wish for an ideal world where standards committees are
- always able quickly to reach a broad consensus based on well-tried
- existing practice, and can deliver a well-rounded document to an
- accepting and grateful public, we have to concern ourself with real
- life.
-
- Real life is populated by engineers with a variety of opinions,
- politicians, lawyers, accountants, and, if you're unlucky, people
- waving guns -- all forces which make it more difficult to achieve what
- may appear to you to be obvious goals. Like you, I, and Uncle Sam,
- they're just doing their jobs, and may consider different goals to be
- obvious. One just has to evaluate how well one is doing despite their
- malign influence.
-
- And I think that requiring conformance to a draft standard is a whole
- lot better than not requiring conformance to anything in particular.
- Sure, it will be annoying and painful to convert later when the real
- thing comes along. And it will cost real money. But it will cost a
- whole lot less money in total than -- say -- implementing using a
- proprietary environment now, and switching to an official POSIX.2 when
- it comes along. Yes, the up-front costs may be higher because a draft
- 9-conforming environment is likely to be more or less custom-built (or
- at least, suppliers are liable to try to stick you for the costs of a
- fully custom job, even if such costs are not justified). But the
- downstream costs, including the costs of any draft-to-final conversion,
- are likely to be way lower.
- --
- Dominic Dunlop
-
- Volume-Number: Volume 21, Number 173
-
- shar.nist.e.24121
- echo nist.f
- cat >nist.f <<'shar.nist.f.24121'
- From std-unix-request@uunet.uu.net Sat Oct 6 17:17:29 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA04337; Sat, 6 Oct 90 17:17:29 -0400
- Posted-Date: 6 Oct 90 14:43:47 GMT
- Received: by cs.utexas.edu (5.64/1.77)
- From: ahby@bungia.bungia.mn.org (Shane P. McCarron)
- Newsgroups: comp.std.unix
- Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
- Message-Id: <13272@cs.utexas.edu>
- References: <558@usenix.ORG> <107019@uunet.UU.NET> <13137@cs.utexas.edu>
- Sender: fletcher@cs.utexas.edu
- Organization: Bugoslavian Embassy, St. Paul, MN
- X-Submissions: std-unix@uunet.uu.net
- Date: 6 Oct 90 14:43:47 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: ahby@bungia.bungia.mn.org (Shane P. McCarron)
-
- In article <13137@cs.utexas.edu> domo@tsa.co.uk writes:
- >Submitted-by: domo@tsa.co.uk (Dominic Dunlop)
- >
- >While we can wish for an ideal world where standards committees are
- >always able quickly to reach a broad consensus based on well-tried
- >existing practice, and can deliver a well-rounded document to an
- >accepting and grateful public, we have to concern ourself with real
- >life.
-
- Dominic says that we have to concern ourselves with real life. Real life
- is that POSIX.2 Draft 9 is an immature document. Making it a
- procurement specification means that system vendors will have to do a
- lot of work that they will, to some extent, just throw away later.
- Moreover, this work will be duplicated by every system vendor wanting
- to sell into that market. Also, since there are organizations like
- the Open Software Foundation and UNIX System Laboratories producing
- reference implementations of the operating system, these vendors could
- have not done the work themselves at all!
-
- This economy is development is something that must be taken into
- account by the US government, and in fact by any organization
- specifying procurement requirements. These organizations want to
- procure something TODAY! They want it to look like a standard
- implementation, but they would probably be just as happy if the
- applications that they really need ran. MS-DOS is not a standard, but
- it runs flight-simulator and Lotus. That's enough for most people.
-
- What we, as people involved in the standardization process, have to do
- is work with the Federal government and other organizations to help
- them understand the folly of prematurely pointing to standards. Those
- standards are, for the most part, build upon existing practice. When
- organizations go to put together a procurement specification, they
- need to know what components of that standard are stable and represent
- existing practice that is available to them TODAY. If they use that
- as the basis of their procurement they will have an Open Systems
- solution that they can actually get their hands on. Further, that
- solution will be upwardly compatible with the final standard because
- it is a proper subset of the functionality in that standard.
-
- A example of reasonable subsetting from Draft 9 would be system limits
- like LINEMAX. In POSIX.2 this is specified as being something like
- 4k (I can't remember). Anyway, the limit is supposed to apply to any
- utility that reads lines of input from the user or from text files.
- No system in the world that is shipping today supports this limit in
- every system utility. It is an ideal goal that the companies represented
- by the participants in POSIX.2 have agreed to move to over time. Producing
- a standard is just that: an agreement that all of "this" existing practice
- is pretty good, and here are the areas in which we agree that it should be
- better defined or enhanced to make the functionality maximally
- advantageous for application developers and end users. This is a very
- important point, and tends to be lost on casual observers of
- standardization efforts.
-
- >And I think that requiring conformance to a draft standard is a whole
- >lot better than not requiring conformance to anything in particular.
- >Sure, it will be annoying and painful to convert later when the real
- >thing comes along. And it will cost real money. But it will cost a
- >whole lot less money in total than -- say -- implementing using a
- >proprietary environment now, and switching to an official POSIX.2 when
- >it comes along. Yes, the up-front costs may be higher because a draft
- >9-conforming environment is likely to be more or less custom-built (or
- >at least, suppliers are liable to try to stick you for the costs of a
- >fully custom job, even if such costs are not justified). But the
- >downstream costs, including the costs of any draft-to-final conversion,
- >are likely to be way lower.
-
- Well, it depends. The cost to the system vendor will be lower, but
- not to the end user. Any functionality that user took advantage of
- that was not represented in the final standard will suddenly become
- non-portable. Worse yet, it may become unavailable. From a system
- vendors perspective, they may have to support some strange
- functioanlity or system limits because the draft standard required
- them to, some agency took advantage of it, and now they are stuck.
- They have to support thios non-portable functionality forever, as well
- as the real standard. This is not at all the goal of standardization,
- and should not be the goal of the agencies procuring systems.
-
- Standing on my soap-box again for a minute, we have to keep the
- overall goal of open systems in sight. That goal is that the
- application developers of the world are given a guaranteed base on
- which they can develop portable applications that can interoperate
- with one another. This means having a steady functional migration
- which NEVER capriciously breaks compatability. This may mean that in
- the short term new, exciting functionality is not introduced to the
- disadvantage of existing practice. This is the price we pay for
- keeping the application developers interested in open systems. The
- personal productivity application base is just coming available for
- open systems platforms in ways that are attractive to the casual
- computer user. We CANNOT abdicate our responsibility to retain that
- extremely hard-won base of applications by allowing radical change in the
- definition of the system. If we do that, we might as well go and buy DOS.
-
- Shane P. McCarron
- Secretary, IEEE TCOS-SS
- --
- Shane P. McCarron Phone: +1 612-224-9239
- Project Manager Internet: ahby@bungia.mn.org
-
-
- Volume-Number: Volume 21, Number 189
-
- shar.nist.f.24121
- echo overview.a
- cat >overview.a <<'shar.overview.a.24121'
- From std-unix-request@uunet.uu.net Fri Oct 12 14:18:50 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA03515; Fri, 12 Oct 90 14:18:50 -0400
- Posted-Date: 12 Oct 90 14:55:22 GMT
- Received: by cs.utexas.edu (5.64/1.78)
- From: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
- Newsgroups: comp.std.unix
- Subject: Re: Internationalisation
- Message-Id: <13523@cs.utexas.edu>
- References: <13501@cs.utexas.edu>
- Sender: fletcher@cs.utexas.edu
- Reply-To: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
- Organization: University of Virginia
- X-Submissions: std-unix@uunet.uu.net
- Date: 12 Oct 90 14:55:22 GMT
- To: std-unix@uunet.uu.net
-
- Submitted-by: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
-
- While I am fond of Vietnamese, I'd like to suggest that it not be
- used in future examples of internationalisation for several reasons
- including the lack of a defined character set standard for Vietnamese.
-
- A number of people, including me, were trying to come up with a reasonable
- modification of the ISO 8859/1 standard and didn't because there are
- too many combinations of diacriticals and vowels for each combination
- to have its own 8-bit representation. The folks behind UNISTD and
- the ISO 32-bit character set proposal are working with Vietnamese in
- mind, so we might eventually have a standard, but for now we don't.
-
- Also, I think the example was erroneous. I think that the example
- was trying to say: "chao` ca'c o^ng" (where the diacriticals belong
- above the vowels not after them and there is no real space in the place
- where the diacritical appears above). Also, I think that the above
- means "Hello everyone" more nearly than "Hello World" (though its early
- in the day and I might well not have the nearest translation either :-)
-
- As I say, It was really nice to see Vietnamese as the example, but I think
- that for this newsgroup it would be more accessible to use a different
- language next time...
-
- Ran
- randall@Virginia.EDU
-
- P.S.
- Persons interested in Vietnamese discussions should move their postings to
- soc.culture.vietnamese from comp.std.unix .
-
-
-
-
-
- Volume-Number: Volume 21, Number 202
-
- shar.overview.a.24121
- echo tag.a
- cat >tag.a <<'shar.tag.a.24121'
- From std-unix-request@uunet.uu.net Mon Oct 1 14:31:10 1990
- Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
- id AA02148; Mon, 1 Oct 90 14:31:10 -0400
- Posted-Date: 1 Oct 90 05:50:43 GMT
- Received: by cs.utexas.edu (5.64/1.76)
- From: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)
- Newsgroups: comp.std.unix,comp.lang.prolog
- Subject: Re: Standards Update, U.S. TAG to ISO/IEC/JTC1/SC22 WG15
- Message-Id: <564@usenix.ORG>
- References: <559@usenix.ORG>
- Sender: jsq@usenix.ORG
- Followup-To: comp.lang.prolog
- Organization: Comp Sci, RMIT, Melbourne, Australia
- X-Submissions: std-unix@uunet.uu.net
- Date: 1 Oct 90 05:50:43 GMT
- Reply-To: std-unix@uunet.uu.net
- To: std-unix@uunet.uu.net
-
- Submitted-by: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)
-
- In article <559@usenix.ORG> in comp.std.unix,
- jsh@usenix.org (Jeffrey S. Haemer) wrote:
-
- > We cannot delay language independence for 1003.1 any longer. It's now
- > really holding up international progress on important POSIX efforts.
- > But what format or technique should we use? ISO rules seem to require
- *************************
- > an ISO-standard method, which could restrict us to VDM (Vienna
- ****************************************************************
- > Definition Method), but no one thinks VDM will work. Paul Rabin and
- ********************
- > Steve Walli have been working on a method, but the TAG worries that a
- > non-standard method will create problems like those we've suffered
- > through with document formats (see last TAG report). In order to
- > avoid rejection later we will circulate the new method in SC22 and
- > WG15 for review and comment. To make this circulation useful, Donn
- > Terry is listing specific questions for SC22 and WG15 to answer.
- > [Editor: I believe that ISO rules only restrict us to VDM if we
- > produce a formal definition, i.e., something from which one could do
- > correctness proofs. Of course, rules and politics are not always the
- > same thing and using VDM might help grease the skids. Still, we
- > should stop and ask if not using VDM would hold us up any more than
- > using VDM.]
-
- My main interest here is in the ISO Prolog standard. I am confused by
- this extract from comp.std.unix, because the ISO Prolog standard
- contains a formal specification of Prolog. Personally, I would find it
- easier to read if it _were_ in VDM. Instead it's in a variant of
- first-order logic (exact semantics unknown) with a new syntax. This
- definition was developed with the explicit intention of permitting
- correctness proofs. Does this mean that ISO _will_ accept "make up your
- own formal specification language", or does it mean that the Prolog
- specification in the ISO Prolog draft is forbidden by ISO rules?
-
- Can someone who really knows clear this up?
-
- --
- Fixed in the next release.
-
- Volume-Number: Volume 21, Number 156
-
- shar.tag.a.24121
- exit
-