home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / reports / 1990.08.followups < prev    next >
Encoding:
Text File  |  1990-10-26  |  162.1 KB  |  3,891 lines

  1. echo 1003.10.a
  2. cat >1003.10.a <<'shar.1003.10.a.24121'
  3. From std-unix-request@uunet.uu.net  Thu Sep  6 20:21:15 1990
  4. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  5.     id AA00653; Thu, 6 Sep 90 20:21:15 -0400
  6. Posted-Date: 7 Sep 90 01:34:25 GMT
  7. Received: by cs.utexas.edu (5.64/1.76) 
  8. From: emv@math.lsa.umich.edu (Edward Vielmetti)
  9. Newsgroups: comp.std.unix
  10. Subject: Re: Standards Update, IEEE 1003.10 and 1003.15: Supercomputing and Batch
  11. Message-Id: <492@usenix.ORG>
  12. References: <485@usenix.ORG>
  13. Sender: std-unix@usenix.ORG
  14. Organization: University of Michigan Math Dept., Ann Arbor MI.
  15. X-Submissions: std-unix@uunet.uu.net
  16. Date: 7 Sep 90 01:34:25 GMT
  17. Reply-To: std-unix@uunet.uu.net
  18. To: std-unix@uunet.uu.net
  19.  
  20. From:  emv@math.lsa.umich.edu (Edward Vielmetti)
  21.  
  22. In article <485@usenix.ORG> jsh@usenix.org (Jeffrey S. Haemer) writes:
  23. [ Well, actually, an anonymous person wrote it; Jeff edited it. -jsq ]
  24.  
  25.    IEEE 1003.10 and 1003.15: Supercomputing and Batch
  26.  
  27.    Just before the close of the meeting, a representative of POSIX.7
  28.    presented some questions about the current direction of the batch
  29.    effort and its relation to the Palladium print system (the Athena
  30.    print system used at MIT).  Many current NQS sites queue print
  31.    requests with NQS, and there has been some interest in defining
  32.    printing features.  That function, however, is clearly within
  33.    POSIX.7's scope.  It is reasonable for POSIX.7 to question if and how
  34.    Palladium and NQS are compatible.
  35.  
  36. For the record, there's an Internet Engineering Task Force group doing
  37. work on defining a Network Printing Protocol.  I enclose the charter
  38. of the group as I find it on nnsc.nsf.net:/ietf/npp-charter.txt.
  39.  
  40. --Ed
  41.  
  42. Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
  43.  
  44. Network Printing Protocol (npp)
  45.  
  46. Charter_
  47.  
  48. Chairperson:
  49.      Leo McLaughlin, ljm@twg.com
  50. Mailing Lists:
  51.      General Discussion:  print-wg@pluto.dss.com
  52.      To Subscribe:  print-wg-request@pluto.dss.com
  53. Description of Working Group:
  54.  
  55.      The Network Printing Working Group has the goal of pursuing
  56.      those issues which will facilitate the use of printers in an
  57.      internetworking environment.  In pursuit of this goal it is
  58.      expected that we will present one or more printing protocols to
  59.      be considered as standards in the Internet community.
  60.      This working group has a number of specific objectives.  To
  61.      provide a draft RFC which will describe the LPR protocol.  To
  62.      describe printing specific issues on topics currently under
  63.      discussion within other working groups (e.g., security and
  64.      dynamic host configuration), to present our concerns to those
  65.      working groups, and to examine printing protocols which exist
  66.      or are currently under development and assess their
  67.      applicability to Internet-wide use, suggesting changes if
  68.      necessary.
  69.  
  70.  
  71. Goals and Milestones:
  72.  
  73. Done          Review and approve the charter, making any changes deemed
  74.               necessary.  Review the problems of printing in the
  75.               Internet.
  76. Apr 1990      Write draft LPR specification.
  77. May 1990      Discuss and review the draft LPR specification.  Discuss
  78.               long-range printing issues in the Internet.  Review
  79.               status of Palladium print system at Project Athena.
  80. May 1990      Submit final LPR specification including changes
  81.               suggested at the May IETF. Discuss document on mailing
  82.               list.
  83. Jun 1990      Submit LPR specification as an RFC and standard.
  84. Jul 1990      Write description of the Palladium printing protocol
  85.               (2.0) in RFC format.
  86. Aug 1990      Discuss and review the draft Palladium RFC.
  87.  
  88. Volume-Number: Volume 21, Number 86
  89.  
  90. shar.1003.10.a.24121
  91. echo 1003.2.a
  92. cat >1003.2.a <<'shar.1003.2.a.24121'
  93. From std-unix-request@uunet.uu.net  Thu Sep 20 19:19:07 1990
  94. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  95.     id AA05804; Thu, 20 Sep 90 19:19:07 -0400
  96. Posted-Date: 20 Sep 90 21:40:50 GMT
  97. Received: by cs.utexas.edu (5.64/1.76) 
  98. From: gwyn@smoke.brl.mil (Doug Gwyn)
  99. Newsgroups: comp.std.unix
  100. Subject: Re: Standards Update, IEEE 1003.2: Shell and tools
  101. Message-Id: <531@usenix.ORG>
  102. References: <530@usenix.ORG>
  103. Sender: jsq@usenix.ORG
  104. Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
  105. X-Submissions: std-unix@uunet.uu.net
  106. Date: 20 Sep 90 21:40:50 GMT
  107. Reply-To: std-unix@uunet.uu.net
  108. To: std-unix@uunet.uu.net
  109.  
  110. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  111.  
  112. In article <530@usenix.ORG> std-unix@uunet.uu.net writes:
  113. -Submitted-by: jsh@usenix.org (Jeffrey S. Haemer)
  114. -   + lint89: This utility is optional, largely because it is
  115. -     controversial for a number of reasons.  Obviously, the very name
  116. -     lint89 is painfully bureaucratic.  Furthermore, many feel that
  117. -     ANSI C makes it unnecessary; moreover, any remaining required
  118. -     functionality rightfully belongs as an additional option in the
  119. -     c89 (cc) utility.  Some point to existing practice.  But what is
  120. -     existing practice when the utility's name is lint89?  [Editor: On
  121. -     the other hand, it may prove indispensable in detecting
  122. -     portability problems in lex89- and yacc89-generated code.
  123. -     Parenthetically, Draft 10 calls these lex and yacc, but that must
  124. -     just be a temporary oversight; the utilities obligatorily have
  125. -     ANSI C input and output.  (One assumes we'll escape c89tags
  126. -     because ctags can be made to work with both flavors.)]
  127.  
  128. I really do not understand the reasoning behind not just using the
  129. names "cc", "lint", "lex", etc.  The entire software generation system
  130. needs to work together as an integrated whole.  Now that there is an
  131. official standard for C, any further standardization involving C should
  132. be connected to standard C.  Since the C standard is in almost all ways
  133. upward-compatible so that "lint", "lex", etc. can be upgraded to support
  134. standard C and still act as before when fed "old K&R C", so long as the
  135. software generation system's C compiler understands lex/yacc/whatever
  136. output there should be no issue here.  From the standards point of view
  137. there should currently be only one notion of what C is.
  138.  
  139.     - D A Gwyn (sporadically acting X3J11/P1003 liaison)
  140.  
  141. Volume-Number: Volume 21, Number 121
  142.  
  143. shar.1003.2.a.24121
  144. echo 1003.2.b
  145. cat >1003.2.b <<'shar.1003.2.b.24121'
  146. From std-unix-request@uunet.uu.net  Fri Sep 21 13:19:38 1990
  147. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  148.     id AA15461; Fri, 21 Sep 90 13:19:38 -0400
  149. Posted-Date: 21 Sep 90 13:47:37 GMT
  150. Received: by cs.utexas.edu (5.64/1.76) 
  151. From: willcox@urbana.mcd.mot.com (David A Willcox)
  152. Newsgroups: comp.std.unix
  153. Subject: Re: Standards Update, IEEE 1003.2: Shell and tools
  154. Message-Id: <532@usenix.ORG>
  155. References: <530@usenix.ORG>
  156. Sender: jsq@usenix.ORG
  157. Organization: Motorola Microcomputer Division, Urbana, IL
  158. X-Submissions: std-unix@uunet.uu.net
  159. Date: 21 Sep 90 13:47:37 GMT
  160. Reply-To: std-unix@uunet.uu.net
  161. To: std-unix@uunet.uu.net
  162.  
  163. Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox)
  164.  
  165. In article <530@usenix.ORG> jsh@usenix.org (Jeffrey S. Haemer) writes:
  166.  
  167. >A few utilities remain contentious:
  168.  
  169. >   + nice, renice: These require underlying functionality absent from
  170. >     POSIX.1, although POSIX.4 has setscheduler(), which allows
  171. >     applications to set priority and scheduling algorithms.
  172.  
  173. A point of clarification:  These utilities, as defined in 1003.2a,
  174. do NOT require any functionality that is not in 1003.1.  Both can be
  175. implemented on a bare-bones 1003.1 system as having no effect on 
  176. execution priority.  The following, for example, is a valid
  177. shell script implementation of nice:
  178.  
  179.     case $1 in
  180.         -n) shift;shift;;
  181.         -*  shift;;
  182.     esac
  183.     exec $*
  184.  
  185. renice is a little more complicated, but not much.  (It should just have
  186. to check for valid arguments.)
  187.  
  188. So saying that you can't implement this on a 1003.1 system is not only
  189. a red herring, it simply isn't true.
  190.  
  191. Providing these utilities allows well-mannered applications to make use
  192. of the priority manipluation features that are already provided by most
  193. implementations.
  194.  
  195. David A. Willcox        "Just say 'NO' to universal drug testing"
  196. Motorola MCD - Urbana        UUCP: ...!uiucuxc!udc!willcox
  197. 1101 E. University Ave.        INET: willcox@urbana.mcd.mot.com
  198. Urbana, IL 61801        FONE: 217-384-8534
  199.  
  200. Volume-Number: Volume 21, Number 122
  201.  
  202. shar.1003.2.b.24121
  203. echo 1003.2.c
  204. cat >1003.2.c <<'shar.1003.2.c.24121'
  205. From std-unix-request@uunet.uu.net  Fri Sep 21 16:19:55 1990
  206. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  207.     id AA12563; Fri, 21 Sep 90 16:19:55 -0400
  208. Posted-Date: 21 Sep 90 18:29:24 GMT
  209. Received: by cs.utexas.edu (5.64/1.76) 
  210. From: rsalz@bbn.com (Rich Salz)
  211. Newsgroups: comp.std.unix
  212. Subject: Re: Standards Update, IEEE 1003.2: Shell and tools
  213. Message-Id: <533@usenix.ORG>
  214. References: <530@usenix.ORG>
  215. Sender: jsq@usenix.ORG
  216. X-Submissions: std-unix@uunet.uu.net
  217. Date: 21 Sep 90 18:29:24 GMT
  218. Reply-To: std-unix@uunet.uu.net
  219. To: std-unix@uunet.uu.net
  220.  
  221. Submitted-by: rsalz@bbn.com (Rich Salz)
  222.  
  223. Reporting on 1003.2 (Shell and tools), in <503@usenix.org> Randall Howard writes:
  224. >+ patch: This utility differs from many others; its origins are in
  225. >  the public domain rather than in a traditional UNIX variants.  As
  226. >  a result, many people feel that patch is worthwhile, but not
  227. >  mature enough to standardize.
  228. I find this sentence totally amazing.
  229.  
  230. Patch has been around far longer, and is much more worthwhile, than more than
  231. 80% of what 1003 has been doing ever since they expanded beyond dot one.
  232.  
  233. Can anyone from the committee who holds this viewpoint offer a reasonable
  234. defense of it?
  235.     /r$
  236.  
  237. Volume-Number: Volume 21, Number 123
  238.  
  239. shar.1003.2.c.24121
  240. echo 1003.4.A
  241. cat >1003.4.A <<'shar.1003.4.A.24121'
  242. From std-unix-request@uunet.uu.net  Tue Sep 25 20:31:03 1990
  243. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  244.     id AA16054; Tue, 25 Sep 90 20:31:03 -0400
  245. Posted-Date: 25 Sep 90 23:09:38 GMT
  246. Received: by cs.utexas.edu (5.64/1.76) 
  247. From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  248. Newsgroups: comp.std.unix
  249. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  250. Message-Id: <544@usenix.ORG>
  251. References: <539@usenix.ORG> <541@usenix.ORG> <543@usenix.ORG>
  252. Sender: jsq@usenix.ORG
  253. Organization: IR
  254. X-Submissions: std-unix@uunet.uu.net
  255. Date: 25 Sep 90 23:09:38 GMT
  256. Reply-To: std-unix@uunet.uu.net
  257. To: std-unix@uunet.uu.net
  258.  
  259. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  260.  
  261. In article <543@usenix.ORG> henry@zoo.toronto.edu (Henry Spencer) writes:
  262. > In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  263. > >In the filesystem abstraction, you open a filename in one stage. You
  264. > >can't do anything between initiating the open and finding out whether or
  265. > >not it succeeds. This just doesn't match reality, and it places a huge
  266. > >restriction on programs that want to do something else while they
  267. > >communicate.
  268. > Programs that want to do two things at once should use explicit parallelism,
  269. > e.g. some sort of threads facility.  In every case I've seen, this yielded
  270. > vastly superior code, with clearer structure and better error handling.
  271.  
  272. I agree that programs that want to do two things at once should use
  273. threads. However, a program that sends out several connection requests
  274. is *not*, in fact, doing several things at once. open() forces it into
  275. an unrealistic local model; surely you agree that this is not a good
  276. semantic match for what actually goes on.
  277.  
  278. That example shows what goes wrong when locality disappears. As another
  279. example, NFS (as it is currently implemented) shows what goes wrong when
  280. reliability disappears. Have you ever run ``df'' on a Sun, only to have
  281. it hang and lock up your terminal? Your process is stuck in kernel mode,
  282. waiting for an NFS server that may be flooded with requests or may have
  283. crashed. Programs that use the filesystem for IPC assume that their
  284. files won't just disappear; this isn't true under NFS.
  285.  
  286. I am not saying that networked filesystems are automatically a bad
  287. thing. Quite the contrary: a distributed filesystem with caching and
  288. other forms of replication can easily be local and reliable, and I'll
  289. gladly see standard UNIX make provisions for it. But something that's
  290. not local, or not reliable, or not static, is also not necessarily
  291. appropriate for the filesystem.
  292.  
  293. ---Dan
  294.  
  295. Volume-Number: Volume 21, Number 132
  296.  
  297. shar.1003.4.A.24121
  298. echo 1003.4.B
  299. cat >1003.4.B <<'shar.1003.4.B.24121'
  300. From std-unix-request@uunet.uu.net  Wed Sep 26 17:30:40 1990
  301. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  302.     id AA19979; Wed, 26 Sep 90 17:30:40 -0400
  303. Posted-Date: 26 Sep 90 12:19:06 GMT
  304. Received: by cs.utexas.edu (5.64/1.76) 
  305. From: ske@pkmab.se (Kristoffer Eriksson)
  306. Newsgroups: comp.std.unix
  307. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  308. Message-Id: <545@usenix.ORG>
  309. References: <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG>
  310. Sender: jsq@usenix.ORG
  311. Organization: Peridot Konsult i Mellansverige AB, Oerebro, Sweden
  312. X-Submissions: std-unix@uunet.uu.net
  313. Date: 26 Sep 90 12:19:06 GMT
  314. Reply-To: std-unix@uunet.uu.net
  315. To: std-unix@uunet.uu.net
  316.  
  317. Submitted-by: ske@pkmab.se (Kristoffer Eriksson)
  318.  
  319. In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  320. >In the filesystem abstraction, you open a filename in one stage. [...]
  321. >
  322. >You can easily construct other examples, but one should be enough to
  323. >convince you that open() just isn't sufficiently general for everything
  324. >that you might read() or write().
  325.  
  326. What prevents us from inventing a few additional filesystem operations
  327. that ARE general enough?
  328.  
  329. I think the important thing about the filesystem abstraction that is being
  330. debated here, is the idea of a common name space, and that idea does not
  331. require open() to be an indivicible operation, and it does not require that
  332. open() must be the only way to associate a file descriptor to a named object,
  333. as long as there is only one name space.
  334. -- 
  335. Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
  336. Phone: +46 19-13 03 60  !  e-mail: ske@pkmab.se
  337. Fax:   +46 19-11 51 03  !  or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske
  338.  
  339. Volume-Number: Volume 21, Number 133
  340.  
  341. shar.1003.4.B.24121
  342. echo 1003.4.C
  343. cat >1003.4.C <<'shar.1003.4.C.24121'
  344. From std-unix-request@uunet.uu.net  Wed Sep 26 17:30:54 1990
  345. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  346.     id AA20052; Wed, 26 Sep 90 17:30:54 -0400
  347. Posted-Date: 26 Sep 90 18:52:59 GMT
  348. Received: by cs.utexas.edu (5.64/1.76) 
  349. From: henry@zoo.toronto.edu (Henry Spencer)
  350. Newsgroups: comp.std.unix
  351. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  352. Message-Id: <546@usenix.ORG>
  353. References: <539@usenix.ORG> <541@usenix.ORG> <543@usenix.ORG> <544@usenix.ORG>
  354. Sender: jsq@usenix.ORG
  355. Organization: U of Toronto Zoology
  356. X-Submissions: std-unix@uunet.uu.net
  357. Date: 26 Sep 90 18:52:59 GMT
  358. Reply-To: std-unix@uunet.uu.net
  359. To: std-unix@uunet.uu.net
  360.  
  361. Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
  362.  
  363. In article <544@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  364. >> Programs that want to do two things at once should use explicit parallelism,
  365. >> e.g. some sort of threads facility.  In every case I've seen, this yielded
  366. >> vastly superior code, with clearer structure and better error handling.
  367. >
  368. >I agree that programs that want to do two things at once should use
  369. >threads. However, a program that sends out several connection requests
  370. >is *not*, in fact, doing several things at once...
  371.  
  372. I'm afraid I don't understand:  a program that is trying, simultaneously,
  373. to open several different connections is somehow not doing several things
  374. at once?  I think this is a confusion of implementation with specification.
  375.  
  376. The program *is* doing several things at once, to wit opening several
  377. connections at once.  If "open" is split into several steps, you can
  378. implement this in a single-threaded program, crudely, by interleaving
  379. the steps of the different opens.  My point is that the code is cleaner,
  380. and often details like good error handling are easier, if you admit that
  381. there is parallel activity here and use explicitly parallel constructs.
  382. Then an "open" that is ready for step 2 does not need to wait for all
  383. the others to finish step 1 first.  And if you do this, there is no need
  384. to decompose "open" at all, because each thread just does all the steps
  385. of one open in sequence.  Furthermore, it can then proceed to do other
  386. useful setup chores, e.g. initial dialog on its connection, without
  387. waiting for the others.  This is a far more natural model of what's
  388. going on than forcing everything into one sequential process, and a
  389. much better match for the semantics of the problem.
  390. -- 
  391. TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
  392. OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry
  393.  
  394. Volume-Number: Volume 21, Number 134
  395.  
  396. shar.1003.4.C.24121
  397. echo 1003.4.D
  398. cat >1003.4.D <<'shar.1003.4.D.24121'
  399. From std-unix-request@uunet.uu.net  Thu Sep 27 13:32:13 1990
  400. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  401.     id AA03547; Thu, 27 Sep 90 13:32:13 -0400
  402. Posted-Date: 27 Sep 90 01:08:56 GMT
  403. Received: by cs.utexas.edu (5.64/1.76) 
  404. From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  405. Newsgroups: comp.std.unix
  406. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  407. Message-Id: <547@usenix.ORG>
  408. References: <543@usenix.ORG> <544@usenix.ORG> <546@usenix.ORG>
  409. Sender: jsq@usenix.ORG
  410. Organization: IR
  411. X-Submissions: std-unix@uunet.uu.net
  412. Date: 27 Sep 90 01:08:56 GMT
  413. Reply-To: std-unix@uunet.uu.net
  414. To: std-unix@uunet.uu.net
  415.  
  416. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  417.  
  418. In article <546@usenix.ORG> henry@zoo.toronto.edu (Henry Spencer) writes:
  419. > I'm afraid I don't understand:  a program that is trying, simultaneously,
  420. > to open several different connections is somehow not doing several things
  421. > at once?
  422.  
  423. Correct. Between sending an open request out upon the network and
  424. receiving an acknowledgment, the program is not doing anything at all
  425. related to that connection.
  426.  
  427. Let me be more specific. Host X, on the Internet, wants to know the
  428. time. It decides to ask ten hosts around the network for the time.
  429.  
  430. In reality, here's what happens in X's interaction with Y: X sends to Y
  431. a request for a connection on port 37. Pause. Y acknowledges. Y sends a
  432. few bytes back and closes the connection. During the pause, X is doing
  433. nothing.
  434.  
  435. But there are several Y's. So X sends out ten requests in sequence. It
  436. waits. Each Y responds at some point; X collects the responses in
  437. whatever order they come. Where is it doing any two things at once, let
  438. alone several?
  439.  
  440. > The program *is* doing several things at once, to wit opening several
  441. > connections at once.
  442.  
  443. ``Opening a connection'' is really an abuse of the language, because a
  444. network open consists of at least two steps that may come arbitrarily
  445. far apart. Let me replace it by phrases that honestly describe what the
  446. computer is doing: ``sending out a connection request, and later
  447. accepting an acknowledgment.''
  448.  
  449. Now, out of the requests and acknowledgments going on, what two are
  450. happening at once? None of them. You're being misled by the terminology.
  451. ``Opening a connection'' is such a common phrase that we automatically
  452. accept it as a description of reality, and consequently believe that it
  453. is well described by open(); but it isn't. The time between request and
  454. acknowledgment is filled with nothing but a void.
  455.  
  456.   [ combining threads with a one-step open() ]
  457. > This is a far more natural model of what's
  458. > going on than forcing everything into one sequential process, and a
  459. > much better match for the semantics of the problem.
  460.  
  461. No. It is not an accurate description of what is going on, since an
  462. open() is implicitly local while a network open is not.
  463.  
  464. Abstract imagery aside, though, ``naturalness'' is really defined by how
  465. a concept helps a programmer. BSD's non-blocking connect() and select()
  466. for connection acceptance, while perhaps not the best-named system
  467. calls, are extremely easy to work with. They adapt perfectly to network
  468. programming problems because they accurately reflect what the system is
  469. doing. In contrast, forking off threads and kludging around a local
  470. open() is unnecessarily complex and would make network programming
  471. unnecessarily difficult. For me that condemns it as an unnatural,
  472. inaccurate reflection of reality.
  473.  
  474. ---Dan
  475.  
  476. Volume-Number: Volume 21, Number 135
  477.  
  478. shar.1003.4.D.24121
  479. echo 1003.4.E
  480. cat >1003.4.E <<'shar.1003.4.E.24121'
  481. From std-unix-request@uunet.uu.net  Thu Sep 27 13:33:06 1990
  482. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  483.     id AA03783; Thu, 27 Sep 90 13:33:06 -0400
  484. Posted-Date: 24 Sep 90 21:56:28 GMT
  485. Received: by cs.utexas.edu (5.64/1.76) 
  486. From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  487. Newsgroups: comp.std.unix
  488. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  489. Message-Id: <548@usenix.ORG>
  490. References: <495@usenix.ORG> <523@usenix.ORG> <529@usenix.ORG>
  491. Sender: jsq@usenix.ORG
  492. Organization: IR
  493. X-Submissions: std-unix@uunet.uu.net
  494. Date: 24 Sep 90 21:56:28 GMT
  495. Reply-To: std-unix@uunet.uu.net
  496. To: std-unix@uunet.uu.net
  497.  
  498. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  499.  
  500. In article <529@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
  501. > According to fouts@bozeman.bozeman.ingr (Martin Fouts):
  502. > >However, the presences of the proc file system is not a strong arguement
  503. > >for the inclusion of othere features in the file system.
  504. > I disagree.  I consider it an excellent example of how the designers
  505. > of Unix realize that all named objects potentially visible to more
  506. > than one process belong in the filesystem namespace.
  507.  
  508. I disagree. I consider it an excellent example of how the designers of
  509. UNIX realize that all *reliable*, *static*, *local* (or virtually local)
  510. I/O objects potentially visible to more than one process belong in the
  511. filesystem namespace.
  512.  
  513. /dev/proc, for example, is reliable---there's no chance of arbitrary
  514. failure. It's static---processes have inertia, and stick around until
  515. they take the positive action of exit()ing. And it's local---you don't
  516. have an arbitrary delay before seeing the information. So it's a
  517. perfectly fine thing to include in the filesystem without hesitation.
  518.  
  519. Objects that aren't reliable, or aren't static, or aren't local, also
  520. aren't necessarily sensible targets of an open(). Some of them might fit
  521. well, but each has to be considered on its own merits.
  522.  
  523. > So, how do we program in such a system?  We use its elegant interface
  524. > -- or should I say "interfaces"?  Plain files, devices, IPCs, and
  525. > network connections each have a semantically accurate interface, which
  526. > unfortunately makes it different from all others.
  527.  
  528. The single UNIX interface is the file descriptor. You can read() or
  529. write() reasonable I/O objects through file descriptors. Very few
  530. programs---the shell is a counterexample---need to worry about what it
  531. takes to set up those file descriptors. Very few programs---stty is a
  532. counterexample---need to know the ioctl()s or other functions that
  533. control the I/O more precisely. What is your complaint?
  534.  
  535. ---Dan
  536.  
  537. Volume-Number: Volume 21, Number 136
  538.  
  539. shar.1003.4.E.24121
  540. echo 1003.4.F
  541. cat >1003.4.F <<'shar.1003.4.F.24121'
  542. From std-unix-request@uunet.uu.net  Thu Sep 27 13:32:28 1990
  543. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  544.     id AA03619; Thu, 27 Sep 90 13:32:28 -0400
  545. Posted-Date: 27 Sep 90 02:06:52 GMT
  546. Received: by cs.utexas.edu (5.64/1.76) 
  547. From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  548. Newsgroups: comp.std.unix
  549. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  550. Message-Id: <549@usenix.ORG>
  551. References: <539@usenix.ORG> <541@usenix.ORG> <545@usenix.ORG>
  552. Sender: jsq@usenix.ORG
  553. Organization: IR
  554. X-Submissions: std-unix@uunet.uu.net
  555. Date: 27 Sep 90 02:06:52 GMT
  556. Reply-To: std-unix@uunet.uu.net
  557. To: std-unix@uunet.uu.net
  558.  
  559. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  560.  
  561. In article <545@usenix.ORG> ske@pkmab.se (Kristoffer Eriksson) writes:
  562. > In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  563.     [ file descriptors are general; the filesystem is not ]
  564. > What prevents us from inventing a few additional filesystem operations
  565. > that ARE general enough?
  566.  
  567. That's a good question. I am willing to believe that a somewhat
  568. different kind of filesystem could sensibly handle I/O objects that are
  569. neither reliable nor local. I find it somewhat harder to believe that
  570. the concept of a filesystem can reasonably reflect dynamic I/O:
  571. information placed into a filesystem should stick around until another
  572. explicit action.
  573.  
  574. In any case, you'll have to invent those operations first.
  575.  
  576. > I think the important thing about the filesystem abstraction that is being
  577. > debated here, is the idea of a common name space,
  578.  
  579. Here's what I thought upon reading this.
  580.  
  581. First: ``A common name space is irrelevant to the most important
  582. properties of a filesystem.''
  583.  
  584. Second: ``A common name space is impossible.''
  585.  
  586. And finally: ``We already have a common name space.''
  587.  
  588. Let me explain. My first thought was that the basic purpose of a
  589. filesystem---to provide reliable, static, local I/O---didn't require a
  590. common name space. As long as there's *some* way to achieve that goal,
  591. you have a filesystem. UNIX has not only some way, but a uniform,
  592. consistent, powerful way: file descriptors.
  593.  
  594. But that's dodging your question. Just because a common name space is
  595. irrelevant to I/O doesn't mean that it may not be helpful for some other
  596. reason. My second thought was that the kind of name space you want is
  597. impossible. You want to include network objects, but no system can
  598. possibly keep track of the tens of thousands of ports under dozens of
  599. protocols on hundreds of thousands of computer. It's just too big.
  600.  
  601. But that's not what you're looking for. Although the name space is huge,
  602. any one computer only looks at a tiny corner of that space. You only
  603. need to see ``current'' names. My third thought: We already have that
  604. common name space! (file,/bin/sh) is in that space. (host,128.122.142.2)
  605. is in that space. (proc,1) is in that space. No system call uses this
  606. common name space, but it's there. Use it at will.
  607.  
  608. ---Dan
  609.  
  610. Volume-Number: Volume 21, Number 137
  611.  
  612. shar.1003.4.F.24121
  613. echo 1003.4.G
  614. cat >1003.4.G <<'shar.1003.4.G.24121'
  615. From std-unix-request@uunet.uu.net  Fri Sep 28 00:31:11 1990
  616. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  617.     id AA27875; Fri, 28 Sep 90 00:31:11 -0400
  618. Posted-Date: 27 Sep 90 17:08:13 GMT
  619. Received: by cs.utexas.edu (5.64/1.76) 
  620. From: tct!chip@cs.utexas.edu (Chip Salzenberg)
  621. Newsgroups: comp.std.unix
  622. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  623. Message-Id: <550@usenix.ORG>
  624. References: <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG>
  625. Sender: jsq@usenix.ORG
  626. Organization: Teltronics/TCT, Sarasota, FL
  627. X-Submissions: std-unix@uunet.uu.net
  628. Date: 27 Sep 90 17:08:13 GMT
  629. Reply-To: std-unix@uunet.uu.net
  630. To: std-unix@uunet.uu.net
  631.  
  632. Submitted-by: chip@tct.uucp (Chip Salzenberg)
  633.  
  634. According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
  635. >The underlying principle is that everything is a file *descriptor*.
  636.  
  637. No one disputes the significance of file descriptors.
  638.  
  639. Nevertheless, it is important not to underestimate the simplification
  640. gained by using one namespace for all objects -- files, devices,
  641. processes, hosts, IPC entities, etc.  A filesystem is good for files,
  642. but a namespace is good for everything.  And if an object has a name,
  643. and you want a file descriptor referring to that object, why invent a
  644. new system call?  I'd rather continue using open().
  645.  
  646. >In reality, you initiate a network stream connection in two stages.
  647. >First you send off a request, which wends its way through the network.
  648. >*Some time later*, the response arrives.
  649.  
  650. This situation is easily modeled with open() and O_NDELAY.  Compare
  651. the way Unix opens a modem control tty.  Normally, the open() call
  652. will block until the carrier detect line is asserted.  However, the
  653. O_NDELAY parameter to open() avoid the blockage.
  654.  
  655. Likewise, an open() on a TCP connection would block until the
  656. connection succeeds or fails.  However, the O_NDELAY parameter would
  657. allow the program to continue immediately, with provisional status of
  658. "success".  The program could come back and check on the open() status
  659. later, perhaps with an fcntl() call.
  660.  
  661. Devices are well-entrenched residents of the filesystem namespace.  So
  662. far, all proposed reasons for keeping network connections out of the
  663. filesystem would apply equally to devices.  Do we really want to leave
  664. the filesytem free of everything except files?  That way lay CP/M.
  665. -- 
  666. Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  667.  
  668. Volume-Number: Volume 21, Number 138
  669.  
  670. shar.1003.4.G.24121
  671. echo 1003.4.H
  672. cat >1003.4.H <<'shar.1003.4.H.24121'
  673. From std-unix-request@uunet.uu.net  Fri Sep 28 00:36:06 1990
  674. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  675.     id AA29892; Fri, 28 Sep 90 00:36:06 -0400
  676. Posted-Date: 27 Sep 90 17:14:30 GMT
  677. Received: by cs.utexas.edu (5.64/1.76) 
  678. From: tct!chip@cs.utexas.edu (Chip Salzenberg)
  679. Newsgroups: comp.std.unix
  680. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  681. Message-Id: <551@usenix.ORG>
  682. References: <541@usenix.ORG> <543@usenix.ORG> <544@usenix.ORG>
  683. Sender: jsq@usenix.ORG
  684. Organization: Teltronics/TCT, Sarasota, FL
  685. X-Submissions: std-unix@uunet.uu.net
  686. Date: 27 Sep 90 17:14:30 GMT
  687. Reply-To: std-unix@uunet.uu.net
  688. To: std-unix@uunet.uu.net
  689.  
  690. Submitted-by: chip@tct.uucp (Chip Salzenberg)
  691.  
  692. According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
  693. >NFS (as it is currently implemented) shows what goes wrong when
  694. >reliability disappears.
  695.  
  696. In a discussion of filesystem semantics, NFS is a straw man.  Everyone
  697. knows it's a botch.
  698.  
  699. If AFS and RFS don't convince one that a networked filesystem
  700. namespace can work well, then nothing will.
  701. -- 
  702. Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  703.  
  704. Volume-Number: Volume 21, Number 139
  705.  
  706. shar.1003.4.H.24121
  707. echo 1003.4.I
  708. cat >1003.4.I <<'shar.1003.4.I.24121'
  709. From std-unix-request@uunet.uu.net  Fri Sep 28 00:39:36 1990
  710. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  711.     id AA01083; Fri, 28 Sep 90 00:39:36 -0400
  712. Posted-Date: 27 Sep 90 12:55:49 GMT
  713. Received: by cs.utexas.edu (5.64/1.76) 
  714. From: rja7m@plaid.cs.Virginia.EDU (Ran Atkinson)
  715. Newsgroups: comp.std.unix
  716. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  717. Message-Id: <552@usenix.ORG>
  718. References: <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG> <545@usenix.ORG>
  719. Sender: jsq@usenix.ORG
  720. Reply-To: randall@Virginia.EDU (Randall Atkinson)
  721. Organization: University of Virginia
  722. X-Submissions: std-unix@uunet.uu.net
  723. Date: 27 Sep 90 12:55:49 GMT
  724. To: std-unix@uunet.uu.net
  725.  
  726. Submitted-by: rja7m@plaid.cs.Virginia.EDU (Ran Atkinson)
  727.  
  728. In article <545@usenix.ORG> ske@pkmab.se (Kristoffer Eriksson) writes:
  729.  
  730. >What prevents us from inventing a few additional filesystem operations
  731. >that ARE general enough?
  732.  
  733. PLEASE.  Let's don't go off inventing new things as part of a standards
  734. effort.  The proper way to approach standardisation is to standardise
  735. the existing practice and avoid all new inventions that haven't been
  736. fully implemented and tested widely.  Many of the problems with UNIX-derived
  737. OSs have come from folks who didn't do this and ended up with stuff that
  738. wasn't really compatible with the rest of the OS in function or approach.
  739.  
  740. A lot of the problems I see coming out of the working groups in P1003
  741. come from folks failing to standardise existing practice and instead
  742. going off and inventing a new idea in the committee that hasn't been
  743. implemented and lacks adequate actual experience with whether the idea
  744. really works and is a general solution to a real problem.  
  745.  
  746.   Randall Atkinson
  747.   randall@Virginia.EDU
  748.  
  749. Volume-Number: Volume 21, Number 140
  750.  
  751. shar.1003.4.I.24121
  752. echo 1003.4.J
  753. cat >1003.4.J <<'shar.1003.4.J.24121'
  754. From std-unix-request@uunet.uu.net  Fri Sep 28 00:43:28 1990
  755. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  756.     id AA02402; Fri, 28 Sep 90 00:43:28 -0400
  757. Posted-Date: 27 Sep 90 20:03:39 GMT
  758. Received: by cs.utexas.edu (5.64/1.76) 
  759. From: tct!chip@cs.utexas.edu (Chip Salzenberg)
  760. Newsgroups: comp.std.unix
  761. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  762. Message-Id: <553@usenix.ORG>
  763. References: <524@usenix.ORG> <528@usenix.ORG> <540@usenix.ORG>
  764. Sender: jsq@usenix.ORG
  765. Organization: Teltronics/TCT, Sarasota, FL
  766. X-Submissions: std-unix@uunet.uu.net
  767. Date: 27 Sep 90 20:03:39 GMT
  768. Reply-To: std-unix@uunet.uu.net
  769. To: std-unix@uunet.uu.net
  770.  
  771. Submitted-by: chip@tct.uucp (Chip Salzenberg)
  772.  
  773. According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
  774. >On the contrary: Given file descriptors, the filesystem is an almost
  775. >useless abstraction.
  776.  
  777. Characterizing the Unix filesystem as "almost useless" is, frankly,
  778. hogwash.  A hierarchical filesystem with mount points is a simple, yet
  779. powerful, organizational tool.
  780.  
  781. To get back to the original point of this thread, one of my primary
  782. complaints about the System V IPC facilities is that they all live in
  783. a flat namespace.  There is no way for me to create a subdirectory for
  784. my application, with naturally named IPCs within that directory.  Such
  785. hierarchical division is "almost useless?"  Hardly.
  786.  
  787. >Many of us are convinced that open() and rename() and unlink() and so on
  788. >are an extremely poor match for unreliable or dynamic or remote I/O.
  789.  
  790. Given Unix, where devices -- even those with removable media -- are
  791. accessed through the filesystem, I can see no reason whatsoever to
  792. treat network connections and other IPC facilities differently.
  793. -- 
  794. Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  795.  
  796. Volume-Number: Volume 21, Number 141
  797.  
  798. shar.1003.4.J.24121
  799. echo 1003.4.K
  800. cat >1003.4.K <<'shar.1003.4.K.24121'
  801. From std-unix-request@uunet.uu.net  Fri Sep 28 14:39:23 1990
  802. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  803.     id AA20823; Fri, 28 Sep 90 14:39:23 -0400
  804. Posted-Date: 28 Sep 90 16:06:42 GMT
  805. Received: by cs.utexas.edu (5.64/1.76) 
  806. From: gwyn@smoke.brl.mil (Doug Gwyn)
  807. Newsgroups: comp.std.unix
  808. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  809. Message-Id: <556@usenix.ORG>
  810. References: <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG>
  811. Sender: jsq@usenix.ORG
  812. Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
  813. X-Submissions: std-unix@uunet.uu.net
  814. Date: 28 Sep 90 16:06:42 GMT
  815. Reply-To: std-unix@uunet.uu.net
  816. To: std-unix@uunet.uu.net
  817.  
  818. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  819.  
  820. In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  821. >In the filesystem abstraction, you open a filename in one stage. You
  822. >can't do anything between initiating the open and finding out whether or
  823. >not it succeeds. This just doesn't match reality, and it places a huge
  824. >restriction on programs that want to do something else while they
  825. >communicate.
  826.  
  827. UNIX was designed explicitly on the model of communicating sequential
  828. processes.  Each process acts as though it executes in a single thread,
  829. blocking when it accesses a resource that is not immediately ready.
  830. While it would be easy to argue that there is a need for improved IPC,
  831. I haven't heard any convincing arguments for making asynchronity
  832. explcitly visible to a process.  In fact, it was considered quite a
  833. step forward in computing back in the old days ("THE" operating system,
  834. for example) when viable means of hiding asynchronity were developed.
  835.  
  836. Volume-Number: Volume 21, Number 144
  837.  
  838. shar.1003.4.K.24121
  839. echo 1003.4.L
  840. cat >1003.4.L <<'shar.1003.4.L.24121'
  841. From std-unix-request@uunet.uu.net  Fri Sep 28 14:40:51 1990
  842. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  843.     id AA21400; Fri, 28 Sep 90 14:40:51 -0400
  844. Posted-Date: 28 Sep 90 16:00:33 GMT
  845. Received: by cs.utexas.edu (5.64/1.76) 
  846. From: gwyn@smoke.brl.mil (Doug Gwyn)
  847. Newsgroups: comp.std.unix
  848. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  849. Message-Id: <557@usenix.ORG>
  850. References: <524@usenix.ORG> <528@usenix.ORG> <540@usenix.ORG>
  851. Sender: jsq@usenix.ORG
  852. Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
  853. X-Submissions: std-unix@uunet.uu.net
  854. Date: 28 Sep 90 16:00:33 GMT
  855. Reply-To: std-unix@uunet.uu.net
  856. To: std-unix@uunet.uu.net
  857.  
  858. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  859.  
  860. In article <540@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  861. >You must convince us that open() makes sense for everything that might
  862. >be a file descriptor, ...
  863.  
  864. open() provides a mechanism for obtaining the object's handle ("file
  865. descriptor") in the first place.  The argument is really about whether
  866. there ought to be more than one way to originate such a handle.  (dup(),
  867. fork(), etc. merely propagate a handle obtained by other means.)  It is
  868. possible, as I described over a year ago in the now-defunct
  869. comp.unix.wizards newsgroup, to design a UNIX-like operating system
  870. where "it takes a handle to get a handle".  However, UNIX is definitely
  871. not like that.  From a software engineering viewpoint, if a single
  872. mechanism for originating handles will suffice, then that is the best
  873. approach.
  874.  
  875. The hierarchical filesystem serves a useful function that you neglected
  876. to mention:  It provides "nodes" at which objects have an opportunity
  877. to contribute to decisions during interpretation of pathnames.  For
  878. example, a directory node plays a very important organizational role,
  879. a device driver node acts like a "portal", nodes act as mount points,
  880. and so on.  Without an identifiable node structure the system would be
  881. severely emaciated.  Indeed, Plan 9 exploits this even more heavily
  882. than does UNIX.
  883.  
  884. Volume-Number: Volume 21, Number 145
  885.  
  886. shar.1003.4.L.24121
  887. echo 1003.4.M
  888. cat >1003.4.M <<'shar.1003.4.M.24121'
  889. From std-unix-request@uunet.uu.net  Sat Sep 29 18:14:17 1990
  890. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  891.     id AA02826; Sat, 29 Sep 90 18:14:17 -0400
  892. Posted-Date: 29 Sep 90 17:07:37 GMT
  893. Received: by cs.utexas.edu (5.64/1.76) 
  894. From: peter@ficc.ferranti.com (Peter da Silva)
  895. Newsgroups: comp.std.unix
  896. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  897. Message-Id: <106697@uunet.UU.NET>
  898. References: <495@usenix.ORG> <523@usenix.ORG> <529@usenix.ORG> <548@usenix.ORG>
  899. Sender: jsq@uunet.uu.net
  900. Reply-To: peter@ficc.ferranti.com (Peter da Silva)
  901. Organization: Xenix Support, FICC
  902. X-Submissions: std-unix@uunet.uu.net
  903. Date: 29 Sep 90 17:07:37 GMT
  904. To: std-unix@uunet.uu.net
  905.  
  906. Submitted-by: peter@ficc.ferranti.com (Peter da Silva)
  907.  
  908. In article <548@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  909. > I disagree. I consider it an excellent example of how the designers of
  910. > UNIX realize that all *reliable*, *static*, *local* (or virtually local)
  911. > I/O objects potentially visible to more than one process belong in the
  912. > filesystem namespace.
  913.  
  914. Like "/dev/tty"? I think you've got some semantic gap here between what's
  915. appropriate for a file versus what's appropriate for a file descriptor. An
  916. arbitrary failure on an open file descriptor causes problems... but that
  917. doesn't keep socket() from returning an fd. An arbitrary failure or an
  918. arbitrary delay on an open call is perfectly reasonable: programs expect
  919. open to fail. They depend on write() working.
  920.  
  921. And serial lines are subject to all the "hazardous" behaviour of network
  922. connections. An open can be indefinitely deferred. The connection, especially
  923. over a modem, can vanish at any time. Why not take *them* out of the namespace
  924. as well?
  925.  
  926. > You can read() or
  927. > write() reasonable I/O objects through file descriptors. Very few
  928. > programs---the shell is a counterexample---need to worry about what it
  929. > takes to set up those file descriptors.
  930.  
  931. And that's the problem, because the shell is the program that is used to
  932. create more file descriptors than just about anything else. If the shell
  933. had a syntax for creating sockets and network connections we wouldn't be
  934. having this discussion... but then if it did then you might as well make
  935. it be via filenames...
  936.  
  937. And look where this discussion started... over shared memory and messages
  938. and semaphores being in a separate namespace. But shared memory and message
  939. ports are all:
  940.  
  941.     reliable,
  942.     static,
  943.     and local...
  944.  
  945. at least as much as processes.
  946. -- 
  947. Peter da Silva.   `-_-'
  948. +1 713 274 5180.   'U`
  949. peter@ferranti.com
  950.  
  951. Volume-Number: Volume 21, Number 150
  952.  
  953. shar.1003.4.M.24121
  954. echo 1003.4.N
  955. cat >1003.4.N <<'shar.1003.4.N.24121'
  956. From std-unix-request@uunet.uu.net  Mon Oct  1 14:32:33 1990
  957. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  958.     id AA02701; Mon, 1 Oct 90 14:32:33 -0400
  959. Posted-Date: 1 Oct 90 14:59:12 GMT
  960. Received: by cs.utexas.edu (5.64/1.76) 
  961. From: peter@ficc.ferranti.com (Peter da Silva)
  962. Newsgroups: comp.std.unix
  963. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  964. Message-Id: <566@usenix.ORG>
  965. References: <543@usenix.ORG> <544@usenix.ORG> <546@usenix.ORG> <547@usenix.ORG>
  966. Sender: jsq@usenix.ORG
  967. Reply-To: peter@ficc.ferranti.com (Peter da Silva)
  968. Organization: Xenix Support, FICC
  969. X-Submissions: std-unix@uunet.uu.net
  970. Date: 1 Oct 90 14:59:12 GMT
  971. To: std-unix@uunet.uu.net
  972.  
  973. Submitted-by: peter@ficc.ferranti.com (Peter da Silva)
  974.  
  975. In article <547@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  976. > ``Opening a connection'' is such a common phrase that we automatically
  977. > accept it as a description of reality, and consequently believe that it
  978. > is well described by open(); but it isn't. The time between request and
  979. > acknowledgment is filled with nothing but a void.
  980.  
  981. There are a *number* of cases in UNIX where an open() does not return in
  982. a determinable time. The correct solution to this is not to pull stuff out
  983. of the file system, but to provide an asynchronous open() call (that can
  984. well be hidden by a threads library, but the mechanism should be there).
  985.  
  986. This is related to the issue of whether network end-points belong in the
  987. file system, but it is not the same issue because there's much more than
  988. networks involved... including objects (serial ports with modem control,
  989. in particular) that are already in the filesystem.
  990.  
  991. Oddly enough, the latest draft of P1003.4 that I have available does NOT
  992. include an asynchronous OPEN request. This is a serious omission.
  993. -- 
  994. Peter da Silva.   `-_-'
  995. +1 713 274 5180.   'U`
  996. peter@ferranti.com
  997.  
  998. Volume-Number: Volume 21, Number 158
  999.  
  1000. shar.1003.4.N.24121
  1001. echo 1003.4.O
  1002. cat >1003.4.O <<'shar.1003.4.O.24121'
  1003. From std-unix-request@uunet.uu.net  Mon Oct  1 14:34:11 1990
  1004. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1005.     id AA03632; Mon, 1 Oct 90 14:34:11 -0400
  1006. Posted-Date: 1 Oct 90 16:26:18 GMT
  1007. Received: by cs.utexas.edu (5.64/1.76) 
  1008. From: donn@hpfcrn.fc.hp.com (Donn Terry)
  1009. Newsgroups: comp.std.unix
  1010. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1011. Message-Id: <107020@uunet.UU.NET>
  1012. References: <106697@uunet.UU.NET>
  1013. Sender: jsq@uunet.uu.net
  1014. X-Submissions: std-unix@uunet.uu.net
  1015. Date: 1 Oct 90 16:26:18 GMT
  1016. Reply-To: std-unix@uunet.uu.net
  1017. To: std-unix@uunet.uu.net
  1018.  
  1019. Submitted-by: donn@hpfcrn.fc.hp.com (Donn Terry)
  1020.  
  1021. I've been following this discussion on the issues of filesystem namespace.
  1022.  
  1023. I'd like to step back from the details and look at it a little 
  1024. more philosophically.  I think that that may lead to a resolution of the
  1025. issues (or at least some progress) (or a decrease in the shrillness)
  1026. (or something).
  1027.  
  1028. UNIX was designed to simplify the programmer's life.  In particular, 
  1029. anything that could be reasonably generalized, was.  This generalization
  1030. is not an easy task, and not easy to explain.  The genius of Ritchie and
  1031. Thompson was both because they acheived the generalization, and because
  1032. they got others to beleive in it.
  1033.  
  1034. The generalization is more difficult to deal with when you are "used to" some
  1035. other model.  (I see folks using various propietary systems griping about
  1036. UNIX because it doesn't do everything just the way they are used to.)
  1037. As Dijkstra once observed about BASIC (I paraphrase, not having the quote).
  1038. "The teaching of BASIC should be forbidden because it forever ruins 
  1039. students from being able to use better languages."
  1040.  
  1041. I think that (although he exaggerates) that Dijkstra's comment also applies
  1042. in this case.  We all are contaminated to some degree or other by the 
  1043. preconceptions we bring with us from other training (be it experience with
  1044. other OSs or something else).
  1045.  
  1046. I have some personal concerns about some of the functionality in 1003.4
  1047. because it appears to be based upon models from other, successful, 
  1048. implementations, but ones that may not have been through the process of
  1049. generalization.  It was R&T's thought that having lots of processes would
  1050. solve such problems, and for the day, it did.  Now it doesn't because of
  1051. tightly coupled activities (tasks?) needing "fast" switch time. 
  1052.  
  1053. To me, threads is the generalization that follows the original philosophy, 
  1054. not bringing up the OS-like functions similar to select() to the user. 
  1055. (I didn't like threads at first, like many don't; I may still not like the
  1056. details, but they do seem to provide the generalization needed for 
  1057. that class of task, without the application writer having to write a
  1058. mini-dispatcher of his/her own.)
  1059.  
  1060. The broad context of namespace is similar, to me.  What's the
  1061. generalization?  I don't really know.  My (UNIX flavored) biases say
  1062. that it's the filesystem.  However, a generalization, not a statement
  1063. that "my problem is different so must be treated differently", is the
  1064. right answer. 
  1065.  
  1066. Let me try something for the readers of this group to think about.
  1067.  
  1068. The "UNIX Filesystem" really consists of two parts:  a heirarchical
  1069. namespace mechanism that currently names objects which are at least
  1070. files, devices, file stores (mounted volumes), and data stream IPC
  1071. mechanisms (OK, FIFOs!).  Some systems add other IPC mechanisms
  1072. (Streams, Sockets), and the process space (/proc.)  I could go on.
  1073.  
  1074. One of the class of objects named in the namespace is ordinary files.
  1075. The set of ordinary files is a collection of flat namespaces, where
  1076. the names are (binary) numbers.  (Each mounted volume is an element
  1077. of the collection, and each i-number is a filename.  The "real names"
  1078. of files are the volume and i-number pair; that's how you tell if two
  1079. files are identical, not by their names in the namespace, of which
  1080. they may have zero or more.)  (The fact that the other object types
  1081. also usually have i-numbers is an accident of implementation.)
  1082.  
  1083. Open() is a means to translate from the namespace to a handle on an object.
  1084. It may be that the handle is for an ordinary file, or for some other 
  1085. object (as I listed above).  Historically, files were the most common
  1086. concept, and the namespace becomes the "filesystem".  (The volume/inode
  1087. namespace isn't, and shouldn't be, accessible, because the gateway
  1088. functions that Doug Gwyn mentions are necessary and valuable.)
  1089.  
  1090. Given the above three paragraphs, one could consciously separate the 
  1091. namespace from the file system further, and then the arguments that 
  1092. "a connection is not a file" seems weaker.  A "connection" is an object
  1093. in the namespace, and open() gives you a handle on it.  Given that you
  1094. know what the object is, you may have to perform additional operations
  1095. on it, or avoid them.  (E.g., many programs operate differently based on the 
  1096. nature of the object they open; if it's a tty it does ioctl() calls on
  1097. it, if not, it doesn't.)
  1098.  
  1099. I'm not yet sure that the "filesystem" namespace is (or is not) the
  1100. right generalization, but a generalization is useful so that we don't
  1101. end up were we were when R&T started out with a bunch of unrelated
  1102. namespaces where, by relating them, common functions could be combined,
  1103. and common operations could be performed commonly.  For example, it
  1104. would be a shame if we find that some network objects that were not put
  1105. in the generic namespace could reasonably have the
  1106. open()/read()/write()/close() model applied to them, and because they
  1107. were in a different namespace, this could not be done (easily).
  1108.  
  1109. Many exisiting proprietary systems (and even more historical ones) left
  1110. you in the state that a program that sequentially read an ordinary file
  1111. couldn't simply do the same thing to a device (without extra programming,
  1112. anyway).  Not looking for the generalization could lead us to the same
  1113. state again for the "newer" technologies.
  1114.  
  1115. Donn Terry
  1116. Speaking only for myself.
  1117.  
  1118. Volume-Number: Volume 21, Number 161
  1119.  
  1120. shar.1003.4.O.24121
  1121. echo 1003.4.P
  1122. cat >1003.4.P <<'shar.1003.4.P.24121'
  1123. From std-unix-request@uunet.uu.net  Mon Oct  1 21:37:46 1990
  1124. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1125.     id AA18471; Mon, 1 Oct 90 21:37:46 -0400
  1126. Posted-Date: 1 Oct 90 20:02:17 GMT
  1127. Received: by cs.utexas.edu (5.64/1.76) 
  1128. From: henry@zoo.toronto.edu (Henry Spencer)
  1129. Newsgroups: comp.std.unix
  1130. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1131. Message-Id: <107042@uunet.UU.NET>
  1132. References: <543@usenix.ORG> <544@usenix.ORG> <546@usenix.ORG> <547@usenix.ORG>
  1133. Sender: jsq@uunet.uu.net
  1134. Organization: U of Toronto Zoology
  1135. X-Submissions: std-unix@uunet.uu.net
  1136. Date: 1 Oct 90 20:02:17 GMT
  1137. Reply-To: std-unix@uunet.uu.net
  1138. To: std-unix@uunet.uu.net
  1139.  
  1140. Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
  1141.  
  1142. In article <547@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  1143. >> The program *is* doing several things at once, to wit opening several
  1144. >> connections at once.
  1145. >
  1146. >``Opening a connection'' is really an abuse of the language, because a
  1147. >network open consists of at least two steps that may come arbitrarily
  1148. >far apart...
  1149.  
  1150. This is the nub of the issue, and it's a difference in semantic models.
  1151. Dan insists on seeing open as a sequence of operations visible to the
  1152. user, in which case his viewpoint is reasonable.  I prefer the Unix
  1153. approach -- the details of an open are none of the user's business,
  1154. only whether it succeeds or fails -- in which case "opening a connection"
  1155. is entirely reasonable terminology, and opening several at once (i.e.
  1156. sending out multiple requests before receiving acknowledgements) is
  1157. indeed doing several things at once, best handled with explicit
  1158. parallelism.
  1159.  
  1160. Both models are defensible, but I would sort of hope that in a Unix
  1161. standard, the Unix model would be employed.
  1162.  
  1163. It is easy to construct examples where explicit parallelism buys you
  1164. things that the multi-step model can't easily achieve, such as writing
  1165. data from one connection to disk while another one is still exchanging
  1166. startup dialog.  One *can* always do this in the multi-step model, but
  1167. it amounts to simulating parallel threads.  The main structure of the
  1168. program turns into:
  1169.  
  1170.     for (;;) {
  1171.         wait for something to happen on some connection
  1172.         deal with it, in such a way that you never block
  1173.     }
  1174.  
  1175. which does work, but greatly obscures the structure of what's going on,
  1176. and tends to require all sorts of strange convolutions in "deal with it"
  1177. because of the requirement that it not block.  (If it blocks, activity
  1178. on *all* connections blocks with it.)  BSDish server code tends to be
  1179. very hard to understand because of exactly this structure.  With multiple
  1180. threads, each one can block whenever convenient, and the others still
  1181. make progress.  Best of all, the individual threads' code looks like a
  1182. standard Unix program:
  1183.  
  1184.     open connection
  1185.     do reads and writes on it and other things as necessary
  1186.     close it
  1187.     exit
  1188.  
  1189. instead of being interwoven into a single master loop with all the rest.
  1190.  
  1191. Almost any program employing select() would be better off using real
  1192. parallelism instead, assuming that costs are similar.  (It is easy to
  1193. make costs so high that parallelism isn't practical.)
  1194. -- 
  1195. Imagine life with OS/360 the standard  | Henry Spencer at U of Toronto Zoology
  1196. operating system.  Now think about X.  |  henry@zoo.toronto.edu   utzoo!henry
  1197.  
  1198. Volume-Number: Volume 21, Number 163
  1199.  
  1200. shar.1003.4.P.24121
  1201. echo 1003.4.Q
  1202. cat >1003.4.Q <<'shar.1003.4.Q.24121'
  1203. From jsq@cs.utexas.edu  Tue Oct  2 13:58:40 1990
  1204. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1205.     id AA25842; Tue, 2 Oct 90 13:58:40 -0400
  1206. Posted-Date: 2 Oct 90 16:16:54 GMT
  1207. Received: by cs.utexas.edu (5.64/1.76) 
  1208. From: donn@hpfcrn.fc.hp.com (Donn Terry)
  1209. Newsgroups: comp.std.unix
  1210. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1211. Message-Id: <13103@cs.utexas.edu>
  1212. References: <556@usenix.ORG> <557@usenix.ORG> <106697@uunet.UU.NET> <566@usenix.ORG> <107020@uunet.UU.NET> <107042@uunet.UU.NET>
  1213. Sender: jsq@cs.utexas.edu
  1214. X-Submissions: std-unix@uunet.uu.net
  1215. Date: 2 Oct 90 16:16:54 GMT
  1216. Reply-To: std-unix@uunet.uu.net
  1217. To: std-unix@uunet.uu.net
  1218.  
  1219. Submitted-by: donn@hpfcrn.fc.hp.com (Donn Terry)
  1220.  
  1221. I was thinking about this a bit more, and want to propose some food for
  1222. thought on the issue.
  1223.  
  1224. Classically, open() is a function that "opens a file descriptor", which
  1225. is where the name comes from.
  1226.  
  1227. However, if you think, rather, of open() as "translate from the (filesystem)
  1228. namespace this string, and give me a handle on the object" it actually makes
  1229. more sense.
  1230.  
  1231. The operations that can be performed on a file are the classical operators
  1232. applicable to such a handle.  However, some are forbidden or meaningless on 
  1233. some object types (lseek on FIFOs, ioctl on ordinary files, some fcntls on
  1234. devices), and some have operations only applicable to them (ioctl on 
  1235. devices) and no other type.  I can easily imagine an object that had none
  1236. of the classical file operations applied to it.
  1237.  
  1238. Now, there is also nothing that requires that open() be the only function
  1239. that returns such a generic object handle.  Imagine (simple example) a
  1240. a heirarchical namespace that contains all possible character
  1241. bitcodes in the namespace.  Open() would not work very well because of the
  1242. null termination and slash rules.  However, I can imagine another function
  1243. that takes a char** as an argument, where each element is the name in
  1244. the next level of the heirarchy.  (With length in the first byte.)  It
  1245. would still return a classical file descriptor.  Similarly, maybe the
  1246. punctuation is different, or the notion of "root" is different; generalizing
  1247. open() to "give me a handle in a namespace" may be most useful.
  1248.  
  1249. I intend this not as any sort of proposal of something that should or should
  1250. not be done, but as an "icebreaker" in terms of thinking about the problem.
  1251.  
  1252. What are the further generalizations we need, how do they make sense and
  1253. fit together, and (the real test of success) what are some of the unexpected
  1254. benefits of the generalization?  (Granting that the "biggest" unexpected
  1255. benefit will show up "later".)
  1256.  
  1257. Donn Terry
  1258. Speaking only for myself.
  1259.  
  1260. Volume-Number: Volume 21, Number 167
  1261.  
  1262. shar.1003.4.Q.24121
  1263. echo 1003.4.R
  1264. cat >1003.4.R <<'shar.1003.4.R.24121'
  1265. From jsq@cs.utexas.edu  Wed Oct  3 08:33:24 1990
  1266. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1267.     id AA25048; Wed, 3 Oct 90 08:33:24 -0400
  1268. Posted-Date: 2 Oct 90 23:04:10 GMT
  1269. Received: by cs.utexas.edu (5.64/1.76) 
  1270. From: fouts@bozeman.bozeman.ingr (Martin Fouts)
  1271. Newsgroups: comp.std.unix
  1272. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1273. Message-Id: <13132@cs.utexas.edu>
  1274. References: <524@usenix.ORG> <528@usenix.ORG> <540@usenix.ORG> <553@usenix.ORG>
  1275. Sender: jsq@cs.utexas.edu
  1276. Organization: INTERGRAPH (APD) -- Palo Alto, CA
  1277. X-Submissions: std-unix@uunet.uu.net
  1278. Date: 2 Oct 90 23:04:10 GMT
  1279. Reply-To: std-unix@uunet.uu.net
  1280. To: std-unix@uunet.uu.net
  1281.  
  1282. Submitted-by: fouts@bozeman.bozeman.ingr (Martin Fouts)
  1283.  
  1284. >>>>> On 27 Sep 90 20:03:39 GMT, chip@tct.uucp (Chip Salzenberg) said:
  1285.  
  1286. Chip> Given Unix, where devices -- even those with removable media -- are
  1287. Chip> accessed through the filesystem, I can see no reason whatsoever to
  1288. Chip> treat network connections and other IPC facilities differently.
  1289. Chip> -- 
  1290.  
  1291. One reason to not treat every IPC facility as part of the file system:
  1292. Shared memory IPC mechanisms which don't need to be visible to
  1293. processes not participating in the IPC.
  1294.  
  1295. Marty
  1296. --
  1297. Martin Fouts
  1298.  
  1299.  UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
  1300.  ARPA:  apd!fouts@ingr.com
  1301. PHONE:  (415) 852-2310            FAX:  (415) 856-9224
  1302.  MAIL:  2400 Geng Road, Palo Alto, CA, 94303
  1303.  
  1304. Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  1305.   -  Frank Zappa
  1306.  
  1307.  
  1308. Volume-Number: Volume 21, Number 169
  1309.  
  1310. shar.1003.4.R.24121
  1311. echo 1003.4.S
  1312. cat >1003.4.S <<'shar.1003.4.S.24121'
  1313. From jsq@cs.utexas.edu  Wed Oct  3 08:53:15 1990
  1314. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1315.     id AA00821; Wed, 3 Oct 90 08:53:15 -0400
  1316. Posted-Date: 3 Oct 90 09:27:45 GMT
  1317. Received: by cs.utexas.edu (5.64/1.76) 
  1318. From: domo@tsa.co.uk (Dominic Dunlop)
  1319. Newsgroups: comp.std.unix
  1320. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1321. Message-Id: <13135@cs.utexas.edu>
  1322. References: <106697@uunet.UU.NET> <107020@uunet.UU.NET>
  1323. Sender: jsq@cs.utexas.edu
  1324. Reply-To: domo@tsa.co.uk
  1325. Organization: The Standard Answer Ltd.
  1326. X-Submissions: std-unix@uunet.uu.net
  1327. Date: 3 Oct 90 09:27:45 GMT
  1328. To: std-unix@uunet.uu.net
  1329.  
  1330. Submitted-by: domo@tsa.co.uk (Dominic Dunlop)
  1331.  
  1332. In article <107020@uunet.UU.NET> donn@hpfcrn.fc.hp.com (Donn Terry) writes
  1333. cogently about file system and other name spaces.  I'm not going to add
  1334. significantly to what he said, merely embroider a little:
  1335.  
  1336. > One of the class of objects named in the namespace is ordinary files.
  1337. > The set of ordinary files is a collection of flat namespaces, where
  1338. > the names are (binary) numbers.  (Each mounted volume is an element
  1339. > of the collection, and each i-number is a filename.  The "real names"
  1340. > of files are the volume and i-number pair; that's how you tell if two
  1341. > files are identical, not by their names in the namespace, of which
  1342. > they may have zero or more.)  (The fact that the other object types
  1343. > also usually have i-numbers is an accident of implementation.)
  1344.  
  1345. I'd just like to add that the existing POSIX.1 standard does incorporate
  1346. the concept of ``a per-file system unique identifier for a file'',
  1347. although its ethnic origins have been disguised by calling it a ``file
  1348. serial number'' rather than an i-number.  The corresponding field in the
  1349. stat structure is, by no coincidence at all, st_ino.
  1350.  
  1351. Donn's point about the need to be able to determine whether two
  1352. ``handles'' (whatever they may be) refer to the same object is a good
  1353. one.  It follows that, if new types of object are made accessible
  1354. through filename space, the information returned by stat() (or fstat())
  1355. should be sufficient uniquely to identify each distinct object.  Of
  1356. course, where the object is not a conventional file, life becomes more
  1357. complex than simply saying that each unique serial number/device id
  1358. combination refers to a unique object.  Although POSIX.1 is 
  1359. reticent on the topic because it is studiously avoiding the UNIX-ism of
  1360. major and minor device numbers, we all know that, faced with a device
  1361. file on a UN*X system, we should ignore the serial number, and use only
  1362. the device id in determining uniqueness.
  1363.  
  1364. I dare say that, as more types of object appear in filename space (and
  1365. I, for one, should like to see them do so), the question of determining
  1366. uniqueness will become knottier.  Suppose, for example, that one used
  1367. filenames as handles for virtual circuits across a wide-area network.
  1368. Conceivably, the number of such circuits could be sufficiently large
  1369. that it will become difficult o shoe-horn a unique identifier into the
  1370. existing stat structure fields.  A problem for the future?
  1371.  
  1372. -- 
  1373. Dominic Dunlop
  1374.  
  1375. Volume-Number: Volume 21, Number 172
  1376.  
  1377. shar.1003.4.S.24121
  1378. echo 1003.4.T
  1379. cat >1003.4.T <<'shar.1003.4.T.24121'
  1380. From jsq@cs.utexas.edu  Wed Oct  3 11:08:06 1990
  1381. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1382.     id AA14297; Wed, 3 Oct 90 11:08:06 -0400
  1383. Posted-Date: 3 Oct 90 15:46:12 GMT
  1384. Received: by cs.utexas.edu (5.64/1.76) 
  1385. From: jason@cnd.hp.com (Jason Zions)
  1386. Newsgroups: comp.std.unix
  1387. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1388. Message-Id: <13142@cs.utexas.edu>
  1389. Sender: jsq@cs.utexas.edu
  1390. Organization: Hewlett Packard, Information Networks Group
  1391. Subject-References: <13132@cs.utexas.edu> <13135@cs.utexas.edu>
  1392. X-Submissions: std-unix@uunet.uu.net
  1393. Date: 3 Oct 90 15:46:12 GMT
  1394. Reply-To: std-unix@uunet.uu.net
  1395. To: std-unix@uunet.uu.net
  1396.  
  1397. Submitted-by: jason@cnd.hp.com (Jason Zions)
  1398.  
  1399. Dominic Dunlop says:
  1400.  
  1401. > I dare say that, as more types of object appear in filename space (and
  1402. > I, for one, should like to see them do so), the question of determining
  1403. > uniqueness will become knottier.  Suppose, for example, that one used
  1404. > filenames as handles for virtual circuits across a wide-area network.
  1405. > Conceivably, the number of such circuits could be sufficiently large
  1406. > that it will become difficult o shoe-horn a unique identifier into the
  1407. > existing stat structure fields.  A problem for the future?
  1408.  
  1409. Actually, a problem for today. P1003.8 has to cope with the fact that a
  1410. local file for major 0, minor 0x010100, inode 1234 is *different* from a
  1411. file on some remote machine with the same (major,minor,inode) triplet. But
  1412. adding a new field or fields to the stat structure isn't gonna work;
  1413. expanding that structure will cause many implementations to shatter (i.e.
  1414. break spectacularly). Just cobbling up a major number for some random
  1415. remotely-mounted filesystem is unsatisfactory, unless the cobble is
  1416. persistant over umount/mount operations. (An application starts to run;
  1417. opens file1 on remsys, gets (maj,min,ino). Network goes down, comes up;
  1418. system remounts remsys. App opens file2 on remsys. That major number had
  1419. better be the same for remsys!)
  1420.  
  1421. What's needed is a simple routine which can be called to determine if two
  1422. handles point to the same object. It would be nice if there was a routine
  1423. which took as arguments a file handle and a path name and returned true iff
  1424. the path referred to the same file. This routine would be guaranteed by the
  1425. implementor to work for any file-system resident object provided for; e.g.
  1426. an SVR4 implementation would have to be able to tell if a file opened via
  1427. RFS referred to the same underlying file as one opened under NFS.
  1428.  
  1429. I don't know if that's sufficient, though; application programmers may be
  1430. using the stat info for other purposes, and a remote_addr field might be a
  1431. good idea. Once P1003.12 decides on a representation for an arbitrary
  1432. network address, which might be considerably larger than an IP address.
  1433.  
  1434. Jason Zions
  1435.  
  1436. Volume-Number: Volume 21, Number 174
  1437.  
  1438. shar.1003.4.T.24121
  1439. echo 1003.4.U
  1440. cat >1003.4.U <<'shar.1003.4.U.24121'
  1441. From jsq@cs.utexas.edu  Wed Oct  3 19:18:59 1990
  1442. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1443.     id AA29364; Wed, 3 Oct 90 19:18:59 -0400
  1444. Posted-Date: 3 Oct 90 17:19:04 GMT
  1445. Received: by cs.utexas.edu (5.64/1.77) 
  1446. From: peter@ficc.ferranti.com (Peter da Silva)
  1447. Newsgroups: comp.std.unix
  1448. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1449. Message-Id: <13156@cs.utexas.edu>
  1450. References: <524@usenix.ORG> <528@usenix.ORG> <540@usenix.ORG> <553@usenix.ORG> <13132@cs.utexas.edu>
  1451. Sender: jsq@cs.utexas.edu
  1452. Reply-To: peter@ficc.ferranti.com (Peter da Silva)
  1453. Organization: Xenix Support, FICC
  1454. X-Submissions: std-unix@uunet.uu.net
  1455. Date: 3 Oct 90 17:19:04 GMT
  1456. To: std-unix@uunet.uu.net
  1457.  
  1458. Submitted-by: peter@ficc.ferranti.com (Peter da Silva)
  1459.  
  1460. In article <13132@cs.utexas.edu> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
  1461. > One reason to not treat every IPC facility as part of the file system:
  1462. > Shared memory IPC mechanisms which don't need to be visible to
  1463. > processes not participating in the IPC.
  1464.  
  1465. Provide an example, considering the advantages of having shell level
  1466. visibility of objects has for (a) debugging, (b) system administration,
  1467. (c) integration, (d)...
  1468.  
  1469. It's nice to be able to fake a program out with a shell script.
  1470. -- 
  1471. Peter da Silva.   `-_-'
  1472. +1 713 274 5180.   'U`
  1473. peter@ferranti.com
  1474.  
  1475. Volume-Number: Volume 21, Number 176
  1476.  
  1477. shar.1003.4.U.24121
  1478. echo 1003.4.V
  1479. cat >1003.4.V <<'shar.1003.4.V.24121'
  1480. From jsq@cs.utexas.edu  Thu Oct  4 10:59:16 1990
  1481. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1482.     id AA02422; Thu, 4 Oct 90 10:59:16 -0400
  1483. Posted-Date: 4 Oct 90 06:21:55 GMT
  1484. Received: by cs.utexas.edu (5.64/1.77) 
  1485. From: aglew@crhc.uiuc.edu (Andy Glew)
  1486. Newsgroups: comp.std.unix
  1487. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1488. Message-Id: <13182@cs.utexas.edu>
  1489. References: <495@usenix.ORG> <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG>
  1490. Sender: jsq@cs.utexas.edu
  1491. Organization: Center for Reliable and High-Performance Computing University of
  1492. X-Submissions: std-unix@uunet.uu.net
  1493. Date: 4 Oct 90 06:21:55 GMT
  1494. Reply-To: std-unix@uunet.uu.net
  1495. To: std-unix@uunet.uu.net
  1496.  
  1497. Submitted-by: aglew@crhc.uiuc.edu (Andy Glew)
  1498.  
  1499. >In the filesystem abstraction, you open a filename in one stage. You
  1500. >can't do anything between initiating the open and finding out whether or
  1501. >not it succeeds. This just doesn't match reality, and it places a huge
  1502. >restriction on programs that want to do something else while they
  1503. >communicate.
  1504.  
  1505. Sounds like you want an asynchronous open facility, much like the
  1506. asynchronous read and write that others already have on their wish
  1507. list for file I/O (and other I/O) (not everyone believes that multiple
  1508. threads are the way to do asynch I/O).
  1509.  
  1510. --
  1511. Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
  1512.  
  1513. Volume-Number: Volume 21, Number 181
  1514.  
  1515. shar.1003.4.V.24121
  1516. echo 1003.4.W
  1517. cat >1003.4.W <<'shar.1003.4.W.24121'
  1518. From jsq@cs.utexas.edu  Thu Oct  4 14:39:03 1990
  1519. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1520.     id AA20321; Thu, 4 Oct 90 14:39:03 -0400
  1521. Posted-Date: 3 Oct 90 20:49:11 GMT
  1522. Received: by cs.utexas.edu (5.64/1.77) 
  1523. From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  1524. Newsgroups: comp.std.unix
  1525. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1526. Message-Id: <13195@cs.utexas.edu>
  1527. References: <529@usenix.ORG> <548@usenix.ORG> <106697@uunet.UU.NET>
  1528. Sender: jsq@cs.utexas.edu
  1529. Organization: IR
  1530. X-Submissions: std-unix@uunet.uu.net
  1531. Date: 3 Oct 90 20:49:11 GMT
  1532. Reply-To: std-unix@uunet.uu.net
  1533. To: std-unix@uunet.uu.net
  1534.  
  1535. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  1536.  
  1537. In article <106697@uunet.UU.NET> peter@ficc.ferranti.com (Peter da Silva) writes:
  1538.   [ Programs depend on write() working. ]
  1539.  
  1540. On the contrary. When the descriptor is unreliable, you get an I/O
  1541. error or the data is simply corrupted; this is exactly what happens with
  1542. disk I/O. Programs that handle errors on read() and write() are more
  1543. robust than programs that don't.
  1544.  
  1545. More commonly, when the descriptor is dynamic and the other side drops,
  1546. you get a broken pipe. This is certainly not a rare failure mode.
  1547.  
  1548. In context, I said that open() is only appropriate for reliable, static,
  1549. local I/O objects. You seem to be arguing that read() and write(), and
  1550. file descriptors in general, also require reliable, static, local I/O
  1551. objects, and so my distinction is silly. But UDP sockets, pipes, and TCP
  1552. sockets are unreliable, dynamic, and remote file descriptors
  1553. respectively, and read()/write() work with them perfectly.
  1554.  
  1555. > > You can read() or
  1556. > > write() reasonable I/O objects through file descriptors. Very few
  1557. > > programs---the shell is a counterexample---need to worry about what it
  1558. > > takes to set up those file descriptors.
  1559. > And that's the problem, because the shell is the program that is used to
  1560. > create more file descriptors than just about anything else. If the shell
  1561. > had a syntax for creating sockets and network connections we wouldn't be
  1562. > having this discussion...
  1563.  
  1564. Oh? Really? I have a syntax for creating sockets and network connections
  1565. from my shell. For example, I just checked an address by typing
  1566.  
  1567.   $ ctcp uunet.uu.net smtp sh -c 'echo expn rsalz>&7;echo quit>&7;cat<&6'
  1568.  
  1569. So we shouldn't be having this discussion, right?
  1570.  
  1571. > but then if it did then you might as well make
  1572. > it be via filenames...
  1573.  
  1574. Why? I don't see a natural filename syntax for TCP connections, so why
  1575. should I try to figure one out? What purpose would it serve? Only two
  1576. programs---a generic client and a generic server---have to understand
  1577. the filenames. If those two programs work, what's the problem?
  1578.  
  1579.   [ shm and sem are reliable, static, local ]
  1580.  
  1581. As a BSD addict I don't have much experience with those features, but I
  1582. believe you're right. So feel free to put shared memory objects into the
  1583. filesystem; I won't argue. Semaphores, I'm not sure about, because it's
  1584. unclear what a file descriptor pointing to a semaphore should mean. Are
  1585. semaphores I/O objects in the first place?
  1586.  
  1587. ---Dan
  1588.  
  1589. Volume-Number: Volume 21, Number 182
  1590.  
  1591. shar.1003.4.W.24121
  1592. echo 1003.4.X
  1593. cat >1003.4.X <<'shar.1003.4.X.24121'
  1594. From jsq@cs.utexas.edu  Fri Oct  5 02:37:08 1990
  1595. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1596.     id AB21718; Fri, 5 Oct 90 02:37:08 -0400
  1597. Posted-Date: 3 Oct 90 19:58:02 GMT
  1598. Received: by cs.utexas.edu (5.64/1.77) 
  1599. From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  1600. Newsgroups: comp.std.unix
  1601. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1602. Message-Id: <13218@cs.utexas.edu>
  1603. References: <543@usenix.ORG> <544@usenix.ORG> <551@usenix.ORG>
  1604. Sender: jsq@cs.utexas.edu
  1605. Organization: IR
  1606. X-Submissions: std-unix@uunet.uu.net
  1607. Date: 3 Oct 90 19:58:02 GMT
  1608. Reply-To: std-unix@uunet.uu.net
  1609. To: std-unix@uunet.uu.net
  1610.  
  1611. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  1612.  
  1613. In article <551@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
  1614. > According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
  1615. > >NFS (as it is currently implemented) shows what goes wrong when
  1616. > >reliability disappears.
  1617. > In a discussion of filesystem semantics, NFS is a straw man.  Everyone
  1618. > knows it's a botch.
  1619. > If AFS and RFS don't convince one that a networked filesystem
  1620. > namespace can work well, then nothing will.
  1621.  
  1622. Exactly! This example proves my point. What's so bad about NFS---why it
  1623. doesn't fit well into the filesystem---is that it doesn't make the
  1624. remote filesystem reliable and local. If you show me Joe Shmoe's RFS
  1625. with reliable, local, static I/O objects, I'll gladly include it in the
  1626. filesystem.
  1627.  
  1628. ---Dan
  1629.  
  1630. Volume-Number: Volume 21, Number 185
  1631.  
  1632. shar.1003.4.X.24121
  1633. echo 1003.4.Y
  1634. cat >1003.4.Y <<'shar.1003.4.Y.24121'
  1635. From jsq@cs.utexas.edu  Fri Oct  5 02:42:14 1990
  1636. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1637.     id AA23596; Fri, 5 Oct 90 02:42:14 -0400
  1638. Posted-Date: 4 Oct 90 20:39:37 GMT
  1639. Received: by cs.utexas.edu (5.64/1.77) 
  1640. From: tct!chip@cs.utexas.edu (Chip Salzenberg)
  1641. Newsgroups: comp.std.unix
  1642. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1643. Message-Id: <13219@cs.utexas.edu>
  1644. References: <540@usenix.ORG> <553@usenix.ORG> <13132@cs.utexas.edu>
  1645. Sender: jsq@cs.utexas.edu
  1646. Organization: Teltronics/TCT, Sarasota, FL
  1647. X-Submissions: std-unix@uunet.uu.net
  1648. Date: 4 Oct 90 20:39:37 GMT
  1649. Reply-To: std-unix@uunet.uu.net
  1650. To: std-unix@uunet.uu.net
  1651.  
  1652. Submitted-by: chip@tct.uucp (Chip Salzenberg)
  1653.  
  1654. According to fouts@bozeman.bozeman.ingr (Martin Fouts):
  1655. >One reason to not treat every IPC facility as part of the file system:
  1656. >Shared memory IPC mechanisms which don't need to be visible to processes
  1657. >not participating in the IPC.
  1658.  
  1659. Yes, it is obviously desirable to have IPC entities without names.
  1660. This feature is a simple extension of the present ability to keep a
  1661. plain file open after its link count falls to zero.  Of course, the
  1662. committee could botch the job by making it an error to completely
  1663. unlink a live IPC.
  1664. -- 
  1665. Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  1666.  
  1667. Volume-Number: Volume 21, Number 186
  1668.  
  1669. shar.1003.4.Y.24121
  1670. echo 1003.4.Z
  1671. cat >1003.4.Z <<'shar.1003.4.Z.24121'
  1672. From std-unix-request@uunet.uu.net  Sat Oct  6 17:10:26 1990
  1673. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1674.     id AA01003; Sat, 6 Oct 90 17:10:26 -0400
  1675. Posted-Date: 5 Oct 90 19:21:41 GMT
  1676. Received: by cs.utexas.edu (5.64/1.77) 
  1677. From: nick@bis.com (Nick Bender)
  1678. Newsgroups: comp.std.unix
  1679. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1680. Summary: write does *not always work*
  1681. Message-Id: <13270@cs.utexas.edu>
  1682. References: <543@usenix.ORG> <544@usenix.ORG> <551@usenix.ORG> <13218@cs.utexas.edu>
  1683. Sender: fletcher@cs.utexas.edu
  1684. Organization: Batterymarch Investment Systems
  1685. X-Submissions: std-unix@uunet.uu.net
  1686. Date: 5 Oct 90 19:21:41 GMT
  1687. Reply-To: std-unix@uunet.uu.net
  1688. To: std-unix@uunet.uu.net
  1689.  
  1690. Submitted-by: nick@bischeops.uucp (Nick Bender)
  1691.  
  1692. In article <13218@cs.utexas.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  1693. = Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  1694. = In article <551@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
  1695. = > According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
  1696. = > >NFS (as it is currently implemented) shows what goes wrong when
  1697. = > >reliability disappears.
  1698. = > In a discussion of filesystem semantics, NFS is a straw man.  Everyone
  1699. = > knows it's a botch.
  1700. = > If AFS and RFS don't convince one that a networked filesystem
  1701. = > namespace can work well, then nothing will.
  1702. = Exactly! This example proves my point. What's so bad about NFS---why it
  1703. = doesn't fit well into the filesystem---is that it doesn't make the
  1704. = remote filesystem reliable and local. If you show me Joe Shmoe's RFS
  1705. = with reliable, local, static I/O objects, I'll gladly include it in the
  1706. = filesystem.
  1707. = ---Dan
  1708.  
  1709. Any program which assumes that write(2) always works is broken. Period.
  1710. That's why you sometimes get long streams of "filesystem full" on your
  1711. console when some brain-damaged utility doesn't check a return value.
  1712. In my view this is not a reason to call NFS a botch.
  1713.  
  1714. nick@bis.com
  1715.  
  1716.  
  1717. Volume-Number: Volume 21, Number 188
  1718.  
  1719. shar.1003.4.Z.24121
  1720. echo 1003.4.a
  1721. cat >1003.4.a <<'shar.1003.4.a.24121'
  1722. From std-unix-request@uunet.uu.net  Fri Aug 24 12:19:40 1990
  1723. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1724.     id AA22813; Fri, 24 Aug 90 12:19:40 -0400
  1725. Posted-Date: 24 Aug 90 03:28:06 GMT
  1726. Received: by cs.utexas.edu (5.64/1.71)
  1727.     id AA06127; Fri, 24 Aug 90 11:19:35 -0500
  1728. From: peter@ficc.ferranti.com (peter da silva)
  1729. Newsgroups: comp.std.unix
  1730. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1731. Message-Id: <457@usenix.ORG>
  1732. References: <448@usenix.ORG>
  1733. Sender: std-unix@usenix.ORG
  1734. Reply-To: ficc.ferranti.com!peter@cs.utexas.edu (Peter da Silva)
  1735. Organization: Xenix Support, FICC
  1736. X-Submissions: std-unix@uunet.uu.net
  1737. Date: 24 Aug 90 03:28:06 GMT
  1738. To: std-unix@uunet.uu.net
  1739.  
  1740. From:  peter@ficc.ferranti.com (peter da silva)
  1741.  
  1742. My personal opinion is that *anything* that can go into the file system name
  1743. space *should*. That's what makes UNIX UNIX... that it's all visible from the
  1744. shell...
  1745. ---
  1746. Peter da Silva.   `-_-'
  1747. +1 713 274 5180.   'U`
  1748. peter@ferranti.com
  1749.  
  1750. Volume-Number: Volume 21, Number 57
  1751.  
  1752. shar.1003.4.a.24121
  1753. echo 1003.4.b
  1754. cat >1003.4.b <<'shar.1003.4.b.24121'
  1755. From std-unix-request@uunet.uu.net  Mon Aug 27 23:40:58 1990
  1756. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1757.     id AA28231; Mon, 27 Aug 90 23:40:58 -0400
  1758. Posted-Date: 27 Aug 90 17:51:57 GMT
  1759. Received: by cs.utexas.edu (5.64/1.74) 
  1760. From: tct!chip@cs.utexas.edu (Chip Salzenberg)
  1761. Newsgroups: comp.std.unix
  1762. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1763. Message-Id: <467@usenix.ORG>
  1764. References: <448@usenix.ORG>
  1765. Sender: std-unix@usenix.ORG
  1766. Organization: Teltronics/TCT, Sarasota, FL
  1767. X-Submissions: std-unix@uunet.uu.net
  1768. Date: 27 Aug 90 17:51:57 GMT
  1769. Reply-To: std-unix@uunet.uu.net
  1770. To: std-unix@uunet.uu.net
  1771.  
  1772. From:  chip@tct.uucp (Chip Salzenberg)
  1773.  
  1774. >     Finally, the group accepted abandoning the use of
  1775. >     file descriptors for semaphore handles, but some participants
  1776. >     wanted to keep semaphore names pathnames.
  1777.  
  1778. Aargh!  Almost everyone realizes that System V IPC is a botch, largely
  1779. because it doesn't live in the filesystem.  So what does IEEE do?
  1780. They take IPC out of the filesystem!
  1781.  
  1782. What sane reason could there be to introduce Yet Another Namespace?
  1783. -- 
  1784. Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  1785.  
  1786. Volume-Number: Volume 21, Number 65
  1787.  
  1788. shar.1003.4.b.24121
  1789. echo 1003.4.c
  1790. cat >1003.4.c <<'shar.1003.4.c.24121'
  1791. From std-unix-request@uunet.uu.net  Tue Aug 28 18:20:30 1990
  1792. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1793.     id AA04815; Tue, 28 Aug 90 18:20:30 -0400
  1794. Posted-Date: 28 Aug 90 11:58:40 GMT
  1795. Received: by cs.utexas.edu (5.64/1.74) 
  1796. From: sp@mysteron.osf.org (Simon Patience)
  1797. Newsgroups: comp.std.unix
  1798. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1799. Message-Id: <470@usenix.ORG>
  1800. References: <448@usenix.ORG> <467@usenix.ORG>
  1801. Sender: std-unix@usenix.ORG
  1802. Reply-To: sp@mysteron.osf.org (Simon Patience)
  1803. Organization: Open Software Foundation
  1804. X-Submissions: std-unix@uunet.uu.net
  1805. Date: 28 Aug 90 11:58:40 GMT
  1806. To: std-unix@uunet.uu.net
  1807.  
  1808. From:  sp@mysteron.osf.org (Simon Patience)
  1809.  
  1810. In article <467@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
  1811. >From:  chip@tct.uucp (Chip Salzenberg)
  1812. >
  1813. >>     Finally, the group accepted abandoning the use of
  1814. >>     file descriptors for semaphore handles, but some participants
  1815. >>     wanted to keep semaphore names pathnames.
  1816. >
  1817. >Aargh!  Almost everyone realizes that System V IPC is a botch, largely
  1818. >because it doesn't live in the filesystem.  So what does IEEE do?
  1819. >They take IPC out of the filesystem!
  1820. >
  1821. >What sane reason could there be to introduce Yet Another Namespace?
  1822.  
  1823. The reason for semaphores not being in the file system is twofold. Some
  1824. realtime embedded systems do not have a file system but do want semaphores
  1825. So this allows them to have them without having to bring in the baggage a
  1826. file system would entail. Secondly, as far as threads, which are supposed to
  1827. be light weight, are concerned it allows semaphores to be implmented in user
  1828. space rather than forcing them into the kernel for the file system.
  1829.  
  1830. A good reason for *not* having IPC handles in the file system is to allow
  1831. network IPC to use the same interfaces. If you have IPC handles in the
  1832. file system then two machines who have applications trying to communicate
  1833. would also have to have at least part of their file system name space to
  1834. be shared. This is non trivial to arrange for two machines so can you
  1835. imaging the problem of doing this for 100 (or 1000?) machines.
  1836.  
  1837. I am just the messenger for these views and do not necessarily hold them
  1838. myself. They were the reasons that came up during the discussion.
  1839.  
  1840. Simon.
  1841.  
  1842.   Simon Patience                Phone: (617) 621-8736
  1843.   Open Software Foundation            FAX:   (617) 225-2782
  1844.   11 Cambridge Center                Email: sp@osf.org
  1845.   Cambridge MA 02142                       uunet!osf.org!sp
  1846.  
  1847. Volume-Number: Volume 21, Number 68
  1848.  
  1849. shar.1003.4.c.24121
  1850. echo 1003.4.d
  1851. cat >1003.4.d <<'shar.1003.4.d.24121'
  1852. From std-unix-request@uunet.uu.net  Wed Aug 29 18:18:41 1990
  1853. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1854.     id AA03017; Wed, 29 Aug 90 18:18:41 -0400
  1855. Posted-Date: 29 Aug 90 14:01:44 GMT
  1856. Received: by cs.utexas.edu (5.64/1.75) 
  1857. From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)
  1858. Newsgroups: comp.std.unix
  1859. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1860. Message-Id: <475@usenix.ORG>
  1861. References: <448@usenix.ORG> <467@usenix.ORG> <470@usenix.ORG>
  1862. Sender: std-unix@usenix.ORG
  1863. Organization: NCR Microelectronics, Ft. Collins, CO
  1864. X-Submissions: std-unix@uunet.uu.net
  1865. Date: 29 Aug 90 14:01:44 GMT
  1866. Reply-To: std-unix@uunet.uu.net
  1867. To: std-unix@uunet.uu.net
  1868.  
  1869. From:  Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)
  1870.  
  1871. >>>>> On 28 Aug 90 11:58:40 GMT, sp@mysteron.osf.org (Simon Patience) said:
  1872. >>     Finally, the group accepted abandoning the use of
  1873. >>     file descriptors for semaphore handles, but some participants
  1874. >>     wanted to keep semaphore names pathnames.
  1875. >>
  1876. >Aargh!  Almost everyone realizes that System V IPC is a botch, largely
  1877. >because it doesn't live in the filesystem.  So what does IEEE do?
  1878. >They take IPC out of the filesystem!
  1879. >
  1880. >What sane reason could there be to introduce Yet Another Namespace?
  1881.  
  1882. Simon> The reason for semaphores not being in the file system is twofold.
  1883. Simon> Some realtime embedded systems do not have a file system but do want
  1884. Simon> semaphores...
  1885.  
  1886. Simon> A good reason for *not* having IPC handles in the file system is to
  1887. Simon> allow network IPC to use the same interfaces.
  1888.  
  1889. How about adding non-file-system-based "handles" to an mmap-like interface?
  1890. (e.g. shmmap(host,porttype,portnum,addr,len,prot,flags)?)  This could
  1891. allow the same interface to be used for network and non-network IPC,
  1892. without the overhead of a trap for every non-network IPC transaction.
  1893.  
  1894. `Scuse me while I don my flame retardant suit...  :-)
  1895.  
  1896. #include <std/disclaimer.h>
  1897. --
  1898. Chuck Phillips  MS440
  1899. NCR Microelectronics             Chuck.Phillips%FtCollins.NCR.com
  1900. 2001 Danfield Ct.
  1901. Ft. Collins, CO.  80525           uunet!ncrlnk!ncr-mpd!bach!chuckp
  1902.  
  1903. Volume-Number: Volume 21, Number 72
  1904.  
  1905. shar.1003.4.d.24121
  1906. echo 1003.4.e
  1907. cat >1003.4.e <<'shar.1003.4.e.24121'
  1908. From std-unix-request@uunet.uu.net  Thu Aug 30 14:18:37 1990
  1909. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1910.     id AA03070; Thu, 30 Aug 90 14:18:37 -0400
  1911. Posted-Date: 30 Aug 90 12:31:01 GMT
  1912. Received: by cs.utexas.edu (5.64/1.76) 
  1913. From: tct!chip@cs.utexas.edu (Chip Salzenberg)
  1914. Newsgroups: comp.std.unix
  1915. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1916. Message-Id: <477@usenix.ORG>
  1917. References: <448@usenix.ORG> <467@usenix.ORG> <470@usenix.ORG>
  1918. Sender: std-unix@usenix.ORG
  1919. Organization: Teltronics/TCT, Sarasota, FL
  1920. X-Submissions: std-unix@uunet.uu.net
  1921. Date: 30 Aug 90 12:31:01 GMT
  1922. Reply-To: std-unix@uunet.uu.net
  1923. To: std-unix@uunet.uu.net
  1924.  
  1925. From:  chip@tct.uucp (Chip Salzenberg)
  1926.  
  1927. According to sp@mysteron.osf.org (Simon Patience):
  1928. >Some realtime embedded systems do not have a file system but do want
  1929. >semaphores.  So this allows them to have them without having to bring
  1930. >in the baggage a file system would entail.
  1931.  
  1932. I was under the impression that POSIX was designing a portable Unix
  1933. interface.  Without a filesystem, you don't have Unix, do you?
  1934. Besides, a given embedded system's library could easily emulate a
  1935. baby-simple filesystem.
  1936.  
  1937. >Secondly, as far as threads, which are supposed to be light weight,
  1938. >are concerned it allows semaphores to be implmented in user space
  1939. >rather than forcing them into the kernel for the file system.
  1940.  
  1941. The desire for user-space support indicates to me that there should be
  1942. some provision for non-filesystem (anonymous) IPCs that can be created
  1943. and used without kernel intervention.  This need does not reduce the
  1944. desirability of putting global IPCs in the filesystem.
  1945.  
  1946. >A good reason for *not* having IPC handles in the file system is to allow
  1947. >network IPC to use the same interfaces.
  1948.  
  1949. Filesystem entities can be used to trigger network activity by the
  1950. kernel (or its stand-in), even if they do not reside on shared
  1951. filesystems.
  1952. -- 
  1953. Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  1954.  
  1955. Volume-Number: Volume 21, Number 74
  1956.  
  1957. shar.1003.4.e.24121
  1958. echo 1003.4.f
  1959. cat >1003.4.f <<'shar.1003.4.f.24121'
  1960. From std-unix-request@uunet.uu.net  Thu Aug 30 14:19:34 1990
  1961. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  1962.     id AA03268; Thu, 30 Aug 90 14:19:34 -0400
  1963. Posted-Date: 30 Aug 90 15:07:04 GMT
  1964. Received: by cs.utexas.edu (5.64/1.76) 
  1965. From: preece@urbana.mcd.mot.com (Scott E. Preece)
  1966. Newsgroups: comp.std.unix
  1967. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  1968. Message-Id: <478@usenix.ORG>
  1969. References: <448@usenix.ORG> <467@usenix.ORG> <470@usenix.ORG>
  1970. Sender: std-unix@usenix.ORG
  1971. Organization: Motorola MCD, Urbana Design Center
  1972. X-Submissions: std-unix@uunet.uu.net
  1973. Date: 30 Aug 90 15:07:04 GMT
  1974. Reply-To: std-unix@uunet.uu.net
  1975. To: std-unix@uunet.uu.net
  1976.  
  1977. From:  preece@urbana.mcd.mot.com (Scott E. Preece)
  1978.  
  1979. | From:  sp@mysteron.osf.org (Simon Patience)
  1980.  
  1981. | The reason for semaphores not being in the file system is twofold. Some
  1982. | realtime embedded systems do not have a file system but do want semaphores
  1983. | So this allows them to have them without having to bring in the baggage a
  1984. | file system would entail.
  1985. ---
  1986. I don't care whether they have something that looks like UNIX filesystem
  1987. code or not, or whether they have disk drives or not, but I don't think
  1988. it's unreasonable to require them to handle semaphore names as though
  1989. they were in a filesystem namespace.  Otherwise you're going to end up
  1990. with a collection of independent features, each minimally specified so
  1991. that it can work without assuming anything else, and anyone with any
  1992. sense is going to say "Yuck" and use a real operating system that
  1993. provides reasonable integration and for a uniform notion of, among other
  1994. things, naming.
  1995. ---
  1996. | ...         Secondly, as far as threads, which are supposed to
  1997. | be light weight, are concerned it allows semaphores to be implmented in user
  1998. | space rather than forcing them into the kernel for the file system.
  1999. ---
  2000. Eh?  I don't know what the group has proposed since the ballot, but it
  2001. would seem that using a filesystem name only makes a difference when you
  2002. first specify you're going to be looking at a particular semaphore,
  2003. which shouldn't be a critical path event.  After that you use a file
  2004. descriptor, which I think could be handled in user space about as well
  2005. as anything else.  In either case you're going to have to go to the
  2006. kernel when scheduling is required (when you block or when you release
  2007. the semaphore).
  2008. ---
  2009. | A good reason for *not* having IPC handles in the file system is to allow
  2010. | network IPC to use the same interfaces. If you have IPC handles in the
  2011. | file system then two machines who have applications trying to communicate
  2012. | would also have to have at least part of their file system name space to
  2013. | be shared. This is non trivial to arrange for two machines so can you
  2014. | imaging the problem of doing this for 100 (or 1000?) machines.
  2015. ---
  2016. You're going to have to synchronize *some* namespace anyway, why
  2017. shouldn't it be a piece of the filesystem namespace?
  2018.  
  2019. A consistent approach to naming and name resolution for ALL global
  2020. objects should be one of the basic requirements for any new POSIX (or
  2021. UNIX!) functionality.  We should have *one* namespace so that we can
  2022. write general tools that only need to know about one namespace.
  2023. --
  2024. scott preece
  2025. motorola/mcd urbana design center    1101 e. university, urbana, il   61801
  2026. uucp:    uunet!uiucuxc!udc!preece,     arpa:    preece@urbana.mcd.mot.com
  2027.  
  2028. Volume-Number: Volume 21, Number 75
  2029.  
  2030. shar.1003.4.f.24121
  2031. echo 1003.4.g
  2032. cat >1003.4.g <<'shar.1003.4.g.24121'
  2033. From std-unix-request@uunet.uu.net  Fri Aug 31 12:19:45 1990
  2034. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2035.     id AA05179; Fri, 31 Aug 90 12:19:45 -0400
  2036. Posted-Date: 31 Aug 90 12:25:17 GMT
  2037. Received: by cs.utexas.edu (5.64/1.76) 
  2038. From: kingdon@ai.mit.edu (Jim Kingdon)
  2039. Newsgroups: comp.std.unix
  2040. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2041. Message-Id: <479@usenix.ORG>
  2042. Sender: std-unix@usenix.ORG
  2043. X-Submissions: std-unix@uunet.uu.net
  2044. Date: 31 Aug 90 12:25:17 GMT
  2045. Reply-To: std-unix@uunet.uu.net
  2046. To: std-unix@uunet.uu.net
  2047.  
  2048. From:  kingdon@ai.mit.edu (Jim Kingdon)
  2049.  
  2050. One obvious (if a little wishy-washy) solution is to not specify
  2051. whether the namespaces are the same.  That is, applications are
  2052. required to use a valid path, and have to be prepared for things like
  2053. unwritable directories, but implementations are not required to check
  2054. for those things.
  2055.  
  2056. This makes sense in light of the fact that there seems to be a general
  2057. lack of consensus about which is best.  Even though there is existing
  2058. practice for both ways of doing things, it may be premature to
  2059. standardize either behavior now.
  2060.  
  2061. Volume-Number: Volume 21, Number 76
  2062.  
  2063. shar.1003.4.g.24121
  2064. echo 1003.4.h
  2065. cat >1003.4.h <<'shar.1003.4.h.24121'
  2066. From std-unix-request@uunet.uu.net  Fri Aug 31 13:18:45 1990
  2067. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2068.     id AA22560; Fri, 31 Aug 90 13:18:45 -0400
  2069. Posted-Date: 31 Aug 90 12:51:35 GMT
  2070. Received: by cs.utexas.edu (5.64/1.76) 
  2071. From: edj@trazadone.westford.ccur.com (Doug Jensen)
  2072. Newsgroups: comp.std.unix
  2073. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2074. Message-Id: <481@usenix.ORG>
  2075. Sender: std-unix@usenix.ORG
  2076. X-Submissions: std-unix@uunet.uu.net
  2077. Date: 31 Aug 90 12:51:35 GMT
  2078. Reply-To: std-unix@uunet.uu.net
  2079. To: std-unix@uunet.uu.net
  2080.  
  2081. From:  Doug Jensen <edj@trazadone.westford.ccur.com>
  2082.  
  2083. 1003.13 is working on real-time AEP's, including one for small embedded
  2084. real-time systems which does not have a file system. So the POSIX answer
  2085. is yes, without the filesystem you still can have a POSIX-compliant
  2086. interface.
  2087.  
  2088. Doug Jensen
  2089. Concurrent Computer Corp.
  2090. edj@westford.ccur.com
  2091.  
  2092. Volume-Number: Volume 21, Number 78
  2093.  
  2094. shar.1003.4.h.24121
  2095. echo 1003.4.i
  2096. cat >1003.4.i <<'shar.1003.4.i.24121'
  2097. From std-unix-request@uunet.uu.net  Thu Sep  6 17:00:11 1990
  2098. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2099.     id AA09428; Thu, 6 Sep 90 17:00:11 -0400
  2100. Posted-Date: 5 Sep 90 15:46:10 GMT
  2101. Received: by cs.utexas.edu (5.64/1.76) 
  2102. From: fouts@bozeman.bozeman.ingr (Martin Fouts)
  2103. Newsgroups: comp.std.unix
  2104. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2105. Message-Id: <488@usenix.ORG>
  2106. References: <448@usenix.ORG> <457@usenix.ORG>
  2107. Sender: std-unix@usenix.ORG
  2108. Organization: INTERGRAPH (APD) -- Palo Alto, CA
  2109. X-Submissions: std-unix@uunet.uu.net
  2110. Date: 5 Sep 90 15:46:10 GMT
  2111. Reply-To: std-unix@uunet.uu.net
  2112. To: std-unix@uunet.uu.net
  2113.  
  2114. From:  fouts@bozeman.bozeman.ingr (Martin Fouts)
  2115.  
  2116. >>>>> On 24 Aug 90 03:28:06 GMT, peter@ficc.ferranti.com (peter da silva) said:
  2117. peter> My personal opinion is that *anything* that can go into the file system name
  2118. peter> space *should*. That's what makes UNIX UNIX... that it's all visible from the
  2119. peter> shell...
  2120.  
  2121. I'm not sure which Unix you've been running for the past five or more
  2122. years, but a lot of stuff doesn't live in the file system name space
  2123. under various BSD derived systems, nor do the networking types believe
  2124. it belongs there.  IMHO neither does a process handle, nor a
  2125. semaphore, and don't even talk to me about "named pipes" as an IPC
  2126. mechanism.
  2127.  
  2128. (Gee, I guess reasonable men might differ on what belongs in the name
  2129. space ;-)
  2130.  
  2131. Marty
  2132. --
  2133. Martin Fouts
  2134.  
  2135.  UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
  2136.  ARPA:  apd!fouts@ingr.com
  2137. PHONE:  (415) 852-2310            FAX:  (415) 856-9224
  2138.  MAIL:  2400 Geng Road, Palo Alto, CA, 94303
  2139.  
  2140. Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  2141.   -  Frank Zappa
  2142.  
  2143. Volume-Number: Volume 21, Number 83
  2144.  
  2145. shar.1003.4.i.24121
  2146. echo 1003.4.j
  2147. cat >1003.4.j <<'shar.1003.4.j.24121'
  2148. From std-unix-request@uunet.uu.net  Thu Sep  6 19:22:22 1990
  2149. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2150.     id AA06538; Thu, 6 Sep 90 19:22:22 -0400
  2151. Posted-Date: 6 Sep 90 21:03:14 GMT
  2152. Received: by cs.utexas.edu (5.64/1.76) 
  2153. From: gwyn@smoke.brl.mil (Doug Gwyn)
  2154. Newsgroups: comp.std.unix
  2155. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2156. Message-Id: <491@usenix.ORG>
  2157. References: <448@usenix.ORG> <457@usenix.ORG> <488@usenix.ORG>
  2158. Sender: std-unix@usenix.ORG
  2159. Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
  2160. X-Submissions: std-unix@uunet.uu.net
  2161. Date: 6 Sep 90 21:03:14 GMT
  2162. Reply-To: std-unix@uunet.uu.net
  2163. To: std-unix@uunet.uu.net
  2164.  
  2165. From:  Doug Gwyn <gwyn@smoke.brl.mil>
  2166.  
  2167. In article <488@usenix.ORG> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
  2168. >I'm not sure which Unix you've been running for the past five or more
  2169. >years, but a lot of stuff doesn't live in the file system name space
  2170. >under various BSD derived systems, nor do the networking types believe
  2171. >it belongs there.
  2172.  
  2173. Excuse me, but the "networking types" I talk to believe that sockets
  2174. were a botch and that network connections definitely DO belong within
  2175. a uniform UNIX "file" name space.  Peter was quite right to note that
  2176. this is an essential feature of UNIX's design.  In fact there are UNIX
  2177. implementations that do this right, 4BSD is simply not among them yet.
  2178.  
  2179. Volume-Number: Volume 21, Number 85
  2180.  
  2181. shar.1003.4.j.24121
  2182. echo 1003.4.k
  2183. cat >1003.4.k <<'shar.1003.4.k.24121'
  2184. From std-unix-request@uunet.uu.net  Fri Sep  7 12:21:22 1990
  2185. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2186.     id AA08917; Fri, 7 Sep 90 12:21:22 -0400
  2187. Posted-Date: 7 Sep 90 02:40:27 GMT
  2188. Received: by cs.utexas.edu (5.64/1.76) 
  2189. From: peter@ficc.ferranti.com (peter da silva)
  2190. Newsgroups: comp.std.unix
  2191. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2192. Message-Id: <493@usenix.ORG>
  2193. References: <448@usenix.ORG> <457@usenix.ORG> <488@usenix.ORG>
  2194. Sender: std-unix@usenix.ORG
  2195. Reply-To: peter@ficc.ferranti.com (Peter da Silva)
  2196. Organization: Xenix Support, FICC
  2197. X-Submissions: std-unix@uunet.uu.net
  2198. Date: 7 Sep 90 02:40:27 GMT
  2199. To: std-unix@uunet.uu.net
  2200.  
  2201. From:  peter da silva <peter@ficc.ferranti.com>
  2202.  
  2203. In article <488@usenix.ORG> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
  2204. > > My personal opinion is that *anything* that can go into the file system
  2205. > > name space *should*. That's what makes UNIX UNIX... that it's all visible
  2206. > > from the shell...
  2207.  
  2208. > I'm not sure which Unix you've been running for the past five or more
  2209. > years, but a lot of stuff doesn't live in the file system name space
  2210. > under various BSD derived systems,
  2211.  
  2212. Yes, and there's even more stuff in System V that doesn't live in that
  2213. name space. In both cases it's *wrong*.
  2214.  
  2215. > nor do the networking types believe
  2216. > it belongs there.
  2217.  
  2218. Some more details on this subject would be advisable. I'm aware that not
  2219. everything *can* go in the file system name space, by the way...
  2220.  
  2221. > IMHO neither does a process handle, nor a
  2222. > semaphore, and don't even talk to me about "named pipes" as an IPC
  2223. > mechanism.
  2224.  
  2225. An active semaphore can be implemented any way you want, but it should
  2226. be represented by an entry in the name space. The same goes for process
  2227. handles and so on.
  2228.  
  2229. Named pipes are an inadequate mechanism for much IPC, but they work quite
  2230. well for many simple cases. If you're looking at them as some sort of
  2231. paragon representing the whole concept, you're sadly mistaken.
  2232.  
  2233. Anyway... what is it that makes "dev/win" more worthy of having an entry
  2234. in "/dev" than "dev/socket"?
  2235. -- 
  2236. Peter da Silva.   `-_-'
  2237. +1 713 274 5180.   'U`
  2238. peter@ferranti.com
  2239.  
  2240. Volume-Number: Volume 21, Number 87
  2241.  
  2242. shar.1003.4.k.24121
  2243. echo 1003.4.l
  2244. cat >1003.4.l <<'shar.1003.4.l.24121'
  2245. From std-unix-request@uunet.uu.net  Fri Sep  7 14:20:39 1990
  2246. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2247.     id AA22362; Fri, 7 Sep 90 14:20:39 -0400
  2248. Posted-Date: 7 Sep 90 15:23:19 GMT
  2249. Received: by cs.utexas.edu (5.64/1.76) 
  2250. From: tct!chip@cs.utexas.edu (Chip Salzenberg)
  2251. Newsgroups: comp.std.unix
  2252. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2253. Message-Id: <495@usenix.ORG>
  2254. References: <448@usenix.ORG> <457@usenix.ORG> <488@usenix.ORG>
  2255. Sender: std-unix@usenix.ORG
  2256. Organization: Teltronics/TCT, Sarasota, FL
  2257. X-Submissions: std-unix@uunet.uu.net
  2258. Date: 7 Sep 90 15:23:19 GMT
  2259. Reply-To: std-unix@uunet.uu.net
  2260. To: std-unix@uunet.uu.net
  2261.  
  2262. From:  chip@tct.uucp (Chip Salzenberg)
  2263.  
  2264. According to fouts@bozeman.bozeman.ingr (Martin Fouts):
  2265. >I'm not sure which Unix you've been running for the past five or more
  2266. >years, but a lot of stuff doesn't live in the file system name space ...
  2267.  
  2268. The absense of sockets (except UNIX domain), System V IPC, etc. from
  2269. the file system is, in the opinion of many, a bug.  It is a result of
  2270. Unix being extended by people who do not understand Unix.
  2271.  
  2272. Research Unix, which is the result of continued development by the
  2273. creators of Unix, did not take things out of the filesystem.  To the
  2274. contrary, it put *more* things there, including processes (via the
  2275. /proc pseudo-directory).
  2276.  
  2277. It is true that other operating systems get along without devices,
  2278. IPC, etc. in their filesystems.  That's fine for them; but it's not
  2279. relevant to Unix.  Unix programming has a history of relying on the
  2280. filesystem to take care of things that other systems handle as special
  2281. cases -- devices, for example.  The idea that devices can be files but
  2282. TCP/IP sockets cannot runs counter to all Unix experience.
  2283.  
  2284. The reason why I continue this discussion here, in comp.std.unix, is
  2285. that many Unix programmers hope that the people in the standardization
  2286. committees have learned from the out-of-filesystem mistake, and will
  2287. rectify it.
  2288. -- 
  2289. Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  2290.  
  2291. Volume-Number: Volume 21, Number 89
  2292.  
  2293. shar.1003.4.l.24121
  2294. echo 1003.4.m
  2295. cat >1003.4.m <<'shar.1003.4.m.24121'
  2296. From std-unix-request@uunet.uu.net  Sat Sep  8 09:21:20 1990
  2297. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2298.     id AA18377; Sat, 8 Sep 90 09:21:20 -0400
  2299. Posted-Date: 8 Sep 90 00:01:00 GMT
  2300. Received: by cs.utexas.edu (5.64/1.76) 
  2301. From: swart@src.dec.com (Garret Swart)
  2302. Newsgroups: comp.std.unix
  2303. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2304. Message-Id: <497@usenix.ORG>
  2305. References: <481@usenix.ORG> <495@usenix.ORG> <488@usenix.ORG> <491@usenix.ORG> <493@usenix.ORG> <479@usenix.ORG>
  2306. Sender: std-unix@usenix.ORG
  2307. X-Submissions: std-unix@uunet.uu.net
  2308. Date: 8 Sep 90 00:01:00 GMT
  2309. Reply-To: std-unix@uunet.uu.net
  2310. To: std-unix@uunet.uu.net
  2311.  
  2312. From:  swart@src.dec.com (Garret Swart)
  2313.  
  2314. I believe in putting lots of interesting stuff in the file system name
  2315. space but I don't believe that semaphores belong there.  The reason
  2316. I don't want to put semaphores in the name space is the same reason
  2317. I don't want to put my program variables in the name space:  I want
  2318. to have lots of them, I want to create and destroy them very quickly
  2319. and I want to operate on them even more quickly.  In other words, the
  2320. granularity is wrong.
  2321.  
  2322. The purpose of a semaphore is to synchronize actions on an object.
  2323. What kinds of objects might one want to synchronize?  Generally the
  2324. objects are either OS supplied like devices or files, or user defined
  2325. data structures.  The typical way of synchronizing files and devices
  2326. is to use advisory locks or the "exclusive use" mode on the device.
  2327. The more difficult case and the one for which semaphores were invented,
  2328. and later added to Unix, is that of synchronizing user data structures.
  2329.  
  2330. In Unix, user data structures may live either in a process's private
  2331. memory or in a shared memory segment.  In both cases there are probably
  2332. many different data structures in that memory and many of these data
  2333. structures may need to be synchronized.  For maximum concurrency the
  2334. programmer may wish to synchronize each data structure with its own
  2335. semaphore.  In many applications these data structures may come and
  2336. go very quickly and the expense of creating a semaphore to synchronize
  2337. the data can be important factor in the performance of the application.
  2338.  
  2339. It thus seems more natural to allow semaphores to be efficiently
  2340. allocated along with the data that they are designed to synchronize.
  2341. That is, allow them to be allocated in a process's private address
  2342. space or in a mapped shared memory segment.  A shared memory segment
  2343. is a much larger grain object, creating, destroying and mapping them
  2344. can be much more expensive than creating, destroying or using a
  2345. semaphore and these segments are generally important enough to the
  2346. application to have sensible names.  Thus putting a shared memory
  2347. segment in the name space seems reasonable.  
  2348.  
  2349. For example, a data base library may use a shared member segment named
  2350. /usr/local/lib/dbm/personnel/bufpool to hold the buffer pool for the
  2351. personnel department's data base.  The data base library would map
  2352. the buffer pool into each client's address space allowing many data
  2353. base client programs to efficiently access the data base.  Each page
  2354. in the buffer pool and each transaction would have its own set of
  2355. semaphores used to synchronize access to the page in the pool or the
  2356. state of a transaction.  Giving the buffer pool a name is no problem,
  2357. but giving each semaphore a name is much more of a hassle.
  2358.  
  2359. [Aside:  Another way of structuring such a data base library is as
  2360. an RPC style multi-threaded server.  This allows access to the data
  2361. base from remote machines and allows easier solutions to the security
  2362. and failure problems inherent in the shared memory approach.  However
  2363. the shared memory approach has a major performance advantage for systems
  2364. that do not support ultra-fast RPCs.  Another approach is to run the
  2365. library in an inner mode.  (Unix has one inner mode called the kernel,
  2366. VMS has 3, Multics had many.)  This solves the security and failure
  2367. problems of the shared segments but it is generally difficult for mere
  2368. mortals to write their own inner mode libraries.]
  2369.  
  2370. One other issue that may cause one to want to unify all objects in
  2371. the file system, at least at the level of using file descriptors to
  2372. refer to all objects if not going so far as to put all objects in the
  2373. name space, is the fact that single threaded programming is much nicer
  2374. if there is a single primitive that will wait for ANY event that the
  2375. process may be interested in (e.g. the 4.2BSD select call.)  This call
  2376. is useful if one is to write a single threaded program that doesn't
  2377. busy wait when it has nothing to do but also won't block when an event
  2378. of interest has occurred.  With the advent of multi-threaded programming
  2379. the single multi-way wait primitive is no longer needed as instead
  2380. one can create a separate thread each blocking for an event of interest
  2381. and processing it.  Multi-way waiting is a problem if single threaded
  2382. programs are going to get maximum use out of the facility.
  2383.  
  2384. I've spoken to a number of people in 1003.4 about these ideas.  I am
  2385. not sure whether it played any part in their decision.
  2386.  
  2387. Just to prove that I am a pro-name space kind of guy, I am currently
  2388. working on and using an experimental file system called Echo that
  2389. integrates the Internet Domain name service for access to global names,
  2390. our internal higher performance name service for highly available
  2391. naming of arbitrary objects, our experimental fault tolerant, log based,
  2392. distributed file service with read/write consistency and universal
  2393. write back for file storage, and auto-mounting NFS for accessing other
  2394. systems.
  2395.  
  2396. Objects that are named in our name space currently include:
  2397.  
  2398.    hosts, users, groups, network servers, network services (a fault
  2399.    tolerant network service is generally provided by several servers),
  2400.    any every version of any source or object file known by our source
  2401.    code control system
  2402.  
  2403. Some of these objects are represented in the name space as a directory
  2404. with auxiliary information, mount points or files stored underneath.
  2405. This subsumes much of the use of special files like /etc/passwd,
  2406. /etc/services and the like in traditional Unix.  Processes are not
  2407. currently in the name space, but they will/should be.  (Just a "simple
  2408. matter of programming.")
  2409.  
  2410. For example /-/com/dec/src/user/swart/home/.draft/6.draft is the name
  2411. of the file I am currently typing, /-/com/dec/src/user/swart/shell
  2412. is a symbolic link to my shell, /-/com/dec/prl/perle/nfs/bin/ls is
  2413. the name of the "ls" program on a vanilla Ultrix machine at DEC's Paris
  2414. Research Lab..
  2415.  
  2416. [Yes, I know we are using "/-/" as the name of the super root and not
  2417. either "/../" or "//" as POSIX mandates, but those other strings are
  2418. so uhhgly and /../ is especially misleading in a system with multiple
  2419. levels of super root, e.g. on my machine "cd /; pwd" types
  2420. /-/com/dec/src.]
  2421.  
  2422. Things that we don't put in the name space are objects that are passed
  2423. within or between processes by 'handle' rather than by name.  For
  2424. example, pipes created with the pipe(2) call, need not be in the name
  2425. space.  [At a further extreme, pipes for intra-process communication
  2426. don't even involve calling the kernel.]
  2427.  
  2428. I personally don't believe in overloading file system operations on
  2429. objects for which the meaning is tenuous (e.g. "unlink" => "kill -TERM"
  2430. on objects of type process); we tend to define new operations for
  2431. manipulating objects of a new type.  But that is even more of a
  2432. digression than I wanted to get into!
  2433.  
  2434. Sorry for the length of this message, I seem to have gotten carried
  2435. away.
  2436.  
  2437. Happy trails,
  2438.  
  2439. Garret Swart
  2440. DEC Systems Research Center
  2441. 130 Lytton Avenue
  2442. Palo Alto, CA 94301
  2443. (415) 853-2220
  2444. decwrl!swart.UUCP or swart@src.dec.com
  2445.  
  2446. Volume-Number: Volume 21, Number 91
  2447.  
  2448. shar.1003.4.m.24121
  2449. echo 1003.4.n
  2450. cat >1003.4.n <<'shar.1003.4.n.24121'
  2451. From std-unix-request@uunet.uu.net  Sat Sep  8 10:20:39 1990
  2452. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2453.     id AA09766; Sat, 8 Sep 90 10:20:39 -0400
  2454. Posted-Date: 8 Sep 90 00:08:48 GMT
  2455. Received: by cs.utexas.edu (5.64/1.76) 
  2456. From: gumby@Cygnus.COM (David Vinayak Wallace)
  2457. Newsgroups: comp.std.unix
  2458. Subject: Standards Update, IEEE 1003.4: Real-time Extensions
  2459. Message-Id: <498@usenix.ORG>
  2460. References: <448@usenix.ORG> <457@usenix.ORG> <488@usenix.ORG> <495@usenix.ORG>
  2461. Sender: std-unix@usenix.ORG
  2462. Organization: Cygnus Support
  2463. X-Submissions: std-unix@uunet.uu.net
  2464. Date: 8 Sep 90 00:08:48 GMT
  2465. Reply-To: std-unix@uunet.uu.net
  2466. To: std-unix@uunet.uu.net
  2467.  
  2468. From: gumby@Cygnus.COM (David Vinayak Wallace)
  2469.  
  2470.    Date: 7 Sep 90 15:23:19 GMT
  2471.    From: chip@tct.uucp (Chip Salzenberg)
  2472. [Most of quoted message deleted.  -mod]
  2473.  
  2474.    It is true that other operating systems get along without devices,
  2475.    IPC, etc. in their filesystems.  That's fine for them; but it's not
  2476.    relevant to Unix.  Unix programming has a history of relying on the
  2477.    filesystem to take care of things that other systems handle as special
  2478.    cases -- devices, for example....
  2479.  
  2480. What defineds `true Unix?'  Don't forget that Multics had all this and
  2481. more in the filesystem; this stuff was REMOVED when Unix was written.
  2482. Is this `continued development by the creators of Unix' just going
  2483. back to what Unix rejected 20 years ago?
  2484.  
  2485. Or for a pun for Multics fans: what goes around comes around...
  2486.  
  2487. Volume-Number: Volume 21, Number 92
  2488.  
  2489. shar.1003.4.n.24121
  2490. echo 1003.4.o
  2491. cat >1003.4.o <<'shar.1003.4.o.24121'
  2492. From std-unix-request@uunet.uu.net  Sun Sep  9 01:39:51 1990
  2493. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2494.     id AA26843; Sun, 9 Sep 90 01:39:51 -0400
  2495. Posted-Date: 8 Sep 90 15:27:10 GMT
  2496. Received: by cs.utexas.edu (5.64/1.76) 
  2497. From: peter@ficc.ferranti.com (Peter da Silva)
  2498. Newsgroups: comp.std.unix
  2499. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2500. Message-Id: <499@usenix.ORG>
  2501. References: <448@usenix.ORG> <457@usenix.ORG> <488@usenix.ORG> <495@usenix.ORG>
  2502. Sender: std-unix@usenix.ORG
  2503. Reply-To: peter@ficc.ferranti.com (Peter da Silva)
  2504. Organization: Xenix Support, FICC
  2505. X-Submissions: std-unix@uunet.uu.net
  2506. Date: 8 Sep 90 15:27:10 GMT
  2507. To: std-unix@uunet.uu.net
  2508.  
  2509. From: peter@ficc.ferranti.com (Peter da Silva)
  2510.  
  2511. Other operating systems have learned from UNIX in this respect, in fact!
  2512.  
  2513. AmigaOS puts all manner of interesting things in the file name space,
  2514. including pipes (PIPE:name), windows (CON:Left/Top/Width/Height/Title/Flags),
  2515. and the environment (ENV:varname). Other things have been left out but are
  2516. being filled in by users (it's relatively easy to wite device handlers on
  2517. AmigaOS). There are some really odd things like PATH:. This can be opened
  2518. as a file and looks like a list of directory names, or used as a directory
  2519. in which case it looks like the concatenation of all the named directories.
  2520. -- 
  2521. Peter da Silva.   `-_-'
  2522. +1 713 274 5180.   'U`
  2523. peter@ferranti.com
  2524.  
  2525. Volume-Number: Volume 21, Number 93
  2526.  
  2527. shar.1003.4.o.24121
  2528. echo 1003.4.p
  2529. cat >1003.4.p <<'shar.1003.4.p.24121'
  2530. From std-unix-request@uunet.uu.net  Tue Sep 11 14:22:38 1990
  2531. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2532.     id AA16709; Tue, 11 Sep 90 14:22:38 -0400
  2533. Posted-Date: 11 Sep 90 03:23:35 GMT
  2534. Received: by cs.utexas.edu (5.64/1.76) 
  2535. From: jfh@rpp386.cactus.org (John F. Haugh II)
  2536. Newsgroups: comp.std.unix
  2537. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2538. Message-Id: <502@usenix.ORG>
  2539. References: <481@usenix.ORG> <495@usenix.ORG> <488@usenix.ORG> <491@usenix.ORG> <493@usenix.ORG> <479@usenix.ORG> <497@usenix.ORG>
  2540. Sender: jsq@usenix.ORG
  2541. Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
  2542. Organization: Lone Star Cafe and BBS Service
  2543. X-Submissions: std-unix@uunet.uu.net
  2544. Date: 11 Sep 90 03:23:35 GMT
  2545. To: std-unix@uunet.uu.net
  2546.  
  2547. From: jfh@rpp386.cactus.org (John F. Haugh II)
  2548.  
  2549. In article <497@usenix.ORG> swart@src.dec.com (Garret Swart) writes:
  2550. >I believe in putting lots of interesting stuff in the file system name
  2551. >space but I don't believe that semaphores belong there.  The reason
  2552. >I don't want to put semaphores in the name space is the same reason
  2553. >I don't want to put my program variables in the name space:  I want
  2554. >to have lots of them, I want to create and destroy them very quickly
  2555. >and I want to operate on them even more quickly.  In other words, the
  2556. >granularity is wrong.
  2557.  
  2558. There is no requirement that you bind every semaphore handle to
  2559. a file system name.  Only that the ability to take a semaphore
  2560. handle and create a file system name or take a file system name
  2561. entry and retreive a semaphore handle.  This would permit you to
  2562. rapidly create and destroy semaphore for private use, as well as
  2563. provide an external interface for public use.
  2564.  
  2565. There is no restriction in either case as to the speed which you
  2566. can perform operations on the handle - file descriptors are
  2567. associated with file system name entries in many cases and I've
  2568. not seen anyone complain that file descriptors slow the system
  2569. down.
  2570. -- 
  2571. John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
  2572. Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
  2573. "SCCS, the source motel!  Programs check in and never check out!"
  2574.         -- Ken Thompson
  2575.  
  2576. Volume-Number: Volume 21, Number 96
  2577.  
  2578. shar.1003.4.p.24121
  2579. echo 1003.4.q
  2580. cat >1003.4.q <<'shar.1003.4.q.24121'
  2581. From std-unix-request@uunet.uu.net  Tue Sep 11 14:23:32 1990
  2582. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2583.     id AA16907; Tue, 11 Sep 90 14:23:32 -0400
  2584. Posted-Date: 11 Sep 90 07:06:23 GMT
  2585. Received: by cs.utexas.edu (5.64/1.76) 
  2586. From: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)
  2587. Newsgroups: comp.std.unix
  2588. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2589. Message-Id: <503@usenix.ORG>
  2590. References: <481@usenix.ORG> <495@usenix.ORG> <488@usenix.ORG> <491@usenix.ORG> <497@usenix.ORG> <497@usenix.ORG>,
  2591. Sender: jsq@usenix.ORG
  2592. Organization: Comp Sci, RMIT, Melbourne, Australia
  2593. X-Submissions: std-unix@uunet.uu.net
  2594. Date: 11 Sep 90 07:06:23 GMT
  2595. Reply-To: std-unix@uunet.uu.net
  2596. To: std-unix@uunet.uu.net
  2597.  
  2598. From: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)
  2599.  
  2600. In article <497@usenix.ORG>, swart@src.dec.com (Garret Swart) writes:
  2601. > I believe in putting lots of interesting stuff in the file system name
  2602. > space but I don't believe that semaphores belong there.  The reason
  2603. > I don't want to put semaphores in the name space is the same reason
  2604. > I don't want to put my program variables in the name space:  I want
  2605. > to have lots of them, I want to create and destroy them very quickly
  2606. > and I want to operate on them even more quickly.  In other words, the
  2607. > granularity is wrong.
  2608.  
  2609. So why not choose a different granularity?  Have the thing that goes in
  2610. the file system name space be an (extensible) *array* of semaphores.
  2611. To specify a semaphore, one would use a (descriptor, index) pair.
  2612. To create a semaphore in a semaphore group, just use it.
  2613. If you want to have a semaphore associated with a data structure in
  2614. mapped memory, just use a lock on the appropriate byte range of the
  2615. mapped file.
  2616.  
  2617. (Am I hopelessly confused, or aren't advisory record locks *already*
  2618. equivalent to binary semaphores?  Trying to lock a range of bytes in
  2619. a file is just a multi-wait, no?  Why do we need two interfaces?  (I
  2620. can see that two or more _implementations_ behind the interface might
  2621. be a good idea, but that's another question.)
  2622. -- 
  2623. Heuer's Law:  Any feature is a bug unless it can be turned off.
  2624.  
  2625. Volume-Number: Volume 21, Number 97
  2626.  
  2627. shar.1003.4.q.24121
  2628. echo 1003.4.r
  2629. cat >1003.4.r <<'shar.1003.4.r.24121'
  2630. From std-unix-request@uunet.uu.net  Wed Sep 12 17:26:34 1990
  2631. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2632.     id AA19542; Wed, 12 Sep 90 17:26:34 -0400
  2633. Posted-Date: 12 Sep 90 16:35:12 GMT
  2634. Received: by cs.utexas.edu (5.64/1.76) 
  2635. From: tct!chip@cs.utexas.edu (Chip Salzenberg)
  2636. Newsgroups: comp.std.unix
  2637. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2638. Message-Id: <508@usenix.ORG>
  2639. References: <488@usenix.ORG> <495@usenix.ORG> <498@usenix.ORG>
  2640. Sender: jsq@usenix.ORG
  2641. Organization: Teltronics/TCT, Sarasota, FL
  2642. X-Submissions: std-unix@uunet.uu.net
  2643. Date: 12 Sep 90 16:35:12 GMT
  2644. Reply-To: std-unix@uunet.uu.net
  2645. To: std-unix@uunet.uu.net
  2646.  
  2647. From: chip@tct.uucp (Chip Salzenberg)
  2648.  
  2649. According to gumby@Cygnus.COM (David Vinayak Wallace):
  2650. >Is this `continued development by the creators of Unix' just going
  2651. >back to what Unix rejected 20 years ago?
  2652.  
  2653. They threw away what wouldn't fit.  Then they added features, but
  2654. piece by piece, and only as they observed a need.
  2655.  
  2656. This cycle has started again with Plan 9, which borrows heavily from
  2657. Unix -- almost everything lives in the filesystem -- but which is in
  2658. fact a brand new start.
  2659.  
  2660. Unix owes much to Multics, and we can learn from it, but we needn't be
  2661. driven by it.
  2662. -- 
  2663. Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  2664.  
  2665. Volume-Number: Volume 21, Number 102
  2666.  
  2667. shar.1003.4.r.24121
  2668. echo 1003.4.s
  2669. cat >1003.4.s <<'shar.1003.4.s.24121'
  2670. From std-unix-request@uunet.uu.net  Mon Sep 17 20:27:05 1990
  2671. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2672.     id AA27220; Mon, 17 Sep 90 20:27:05 -0400
  2673. Posted-Date: 17 Sep 90 21:02:49 GMT
  2674. Received: by cs.utexas.edu (5.64/1.76) 
  2675. From: fouts@bozeman.bozeman.ingr (Martin Fouts)
  2676. Newsgroups: comp.std.unix
  2677. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2678. Message-Id: <523@usenix.ORG>
  2679. References: <448@usenix.ORG> <457@usenix.ORG> <488@usenix.ORG> <495@usenix.ORG>
  2680. Sender: jsq@usenix.ORG
  2681. Organization: INTERGRAPH (APD) -- Palo Alto, CA
  2682. X-Submissions: std-unix@uunet.uu.net
  2683. Date: 17 Sep 90 21:02:49 GMT
  2684. Reply-To: std-unix@uunet.uu.net
  2685. To: std-unix@uunet.uu.net
  2686.  
  2687. Submitted-by: fouts@bozeman.bozeman.ingr (Martin Fouts)
  2688.  
  2689. >>>>> On 7 Sep 90 15:23:19 GMT, chip@tct.uucp (Chip Salzenberg) said:
  2690.  
  2691. Chip> According to fouts@bozeman.bozeman.ingr (Martin Fouts):
  2692. >I'm not sure which Unix you've been running for the past five or more
  2693. >years, but a lot of stuff doesn't live in the file system name space ...
  2694.  
  2695. Chip> The absense of sockets (except UNIX domain), System V IPC, etc. from
  2696. Chip> the file system is, in the opinion of many, a bug.  It is a result of
  2697. Chip> Unix being extended by people who do not understand Unix.
  2698.                              ^-------------------------------^
  2699.  
  2700. My aren't we superior.  (;-) At one time, I believed that sockets
  2701. belonged in the filesystem name space.  I spent a long time arguing
  2702. this point with members of the networking community before they
  2703. convinced me that certain transient objects do not belong in that name
  2704. space.  (See below)
  2705.  
  2706. Chip> Research Unix, which is the result of continued development by the
  2707. Chip> creators of Unix, did not take things out of the filesystem.  To the
  2708. Chip> contrary, it put *more* things there, including processes (via the
  2709. Chip> /proc pseudo-directory).
  2710.  
  2711. The value of proc in the file system are debatable.  Certain debugging
  2712. tools are easier to hang on an fcntl certain others are not.  However, the
  2713. presences of the proc file system is not a strong arguement for the
  2714. inclusion of othere features in the file system.
  2715.  
  2716. Chip> It is true that other operating systems get along without devices,
  2717. Chip> IPC, etc. in their filesystems.  That's fine for them; but it's not
  2718. Chip> relevant to Unix.  Unix programming has a history of relying on the
  2719. Chip> filesystem to take care of things that other systems handle as special
  2720. Chip> cases -- devices, for example.  The idea that devices can be files but
  2721. Chip> TCP/IP sockets cannot runs counter to all Unix experience.
  2722.  
  2723. Unix programming has a history of using the filesystem for some things
  2724. and not using it for others.  For example, I can demonstrate a
  2725. semantic under which it is possible to put the time of day clock into
  2726. the file system and reference it by opening the i.e. /dev/timeofday
  2727. file.  Each time I read from that file, I would get the current time.
  2728. Via fcntls, I could extend this to handle timer functions.  It wasn't
  2729. done in Unix.  (I've done similar things in other OSs I've designed,
  2730. though.)
  2731.  
  2732. The whole point of the response which you partially quoted was to
  2733. remind the poster I was responding to that not all functions which
  2734. might have been placed in the filesystem automatically have.
  2735.  
  2736. Chip> The reason why I continue this discussion here, in comp.std.unix, is
  2737. Chip> that many Unix programmers hope that the people in the standardization
  2738. Chip> committees have learned from the out-of-filesystem mistake, and will
  2739. Chip> rectify it.
  2740. Chip> --
  2741.  
  2742. The reason I respond is that it is not automatically safe to assume
  2743. that something belongs in the file system because something else is
  2744. already there.  There is also an explicit problem not mentioned in
  2745. this discussion which is the distinction between filesystem name space
  2746. and filesystem semantics.  Sometimes there are objects which would be
  2747. reasonable to treat with filesystem semantics for which there is no
  2748. reasonable mechanism for introducing them into the filesystem name
  2749. space.  Because of the way network connections are made, I have been
  2750. convinced by networking experts (who are familiar with the "Unix
  2751. style") that the filesystem namespace does not have a good semantic
  2752. match for the network name space.
  2753.  
  2754. Chip> Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  2755.  
  2756. Chip> Volume-Number: Volume 21, Number 89
  2757.  
  2758. Marty
  2759. --
  2760. Martin Fouts
  2761.  
  2762.  UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
  2763.  ARPA:  apd!fouts@ingr.com
  2764. PHONE:  (415) 852-2310            FAX:  (415) 856-9224
  2765.  MAIL:  2400 Geng Road, Palo Alto, CA, 94303
  2766.  
  2767. Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  2768.   -  Frank Zappa
  2769.  
  2770. Volume-Number: Volume 21, Number 114
  2771.  
  2772. shar.1003.4.s.24121
  2773. echo 1003.4.t
  2774. cat >1003.4.t <<'shar.1003.4.t.24121'
  2775. From std-unix-request@uunet.uu.net  Tue Sep 18 18:19:33 1990
  2776. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2777.     id AA25986; Tue, 18 Sep 90 18:19:33 -0400
  2778. Posted-Date: 18 Sep 90 20:03:32 GMT
  2779. Received: by cs.utexas.edu (5.64/1.76) 
  2780. From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  2781. Newsgroups: comp.std.unix
  2782. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2783. Message-Id: <524@usenix.ORG>
  2784. References: <488@usenix.ORG> <495@usenix.ORG> <523@usenix.ORG>
  2785. Sender: jsq@usenix.ORG
  2786. Organization: IR
  2787. X-Submissions: std-unix@uunet.uu.net
  2788. Date: 18 Sep 90 20:03:32 GMT
  2789. Reply-To: std-unix@uunet.uu.net
  2790. To: std-unix@uunet.uu.net
  2791.  
  2792. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  2793.  
  2794. In article <523@usenix.ORG> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
  2795. > At one time, I believed that sockets
  2796. > belonged in the filesystem name space.  I spent a long time arguing
  2797. > this point with members of the networking community before theyy
  2798. > convinced me that certain transient objects do not belong in that name
  2799. > space.
  2800.  
  2801. In contrast, I've found it quite easy to get people to agree that
  2802. practically every object should be usable as an open *file*. The beauty
  2803. and power of UNIX is the abstraction of files---not filesystems. I'd say
  2804. that the concept of an open file descriptor is one of the most important
  2805. reasons that UNIX-style operating systems are taking over the world.
  2806.  
  2807. chip@tct.uucp (Chip Salzenberg) writes:
  2808. > The reason why I continue this discussion here, in comp.std.unix, is
  2809. > that many Unix programmers hope that the people in the standardization
  2810. > committees have learned from the out-of-filesystem mistake, and will
  2811. > rectify it.
  2812.  
  2813. I am a UNIX programmer who strongly hopes that standards committees will
  2814. never make the mistake of putting network objects into the filesystem.
  2815. Although the semantics of read() and write() fit network connections
  2816. perfectly, the semantics of open() most certainly do not. I will readily
  2817. support passing network connections as file descriptors. I will fight
  2818. tooth and nail to make sure that they need not be passed as filenames.
  2819.  
  2820. ---Dan
  2821.  
  2822. Volume-Number: Volume 21, Number 115
  2823.  
  2824. shar.1003.4.t.24121
  2825. echo 1003.4.u
  2826. cat >1003.4.u <<'shar.1003.4.u.24121'
  2827. From std-unix-request@uunet.uu.net  Thu Sep 20 14:19:56 1990
  2828. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2829.     id AA10651; Thu, 20 Sep 90 14:19:56 -0400
  2830. Posted-Date: 20 Sep 90 12:53:46 GMT
  2831. Received: by cs.utexas.edu (5.64/1.76) 
  2832. From: tct!chip@cs.utexas.edu (Chip Salzenberg)
  2833. Newsgroups: comp.std.unix
  2834. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2835. Message-Id: <528@usenix.ORG>
  2836. References: <495@usenix.ORG> <523@usenix.ORG> <524@usenix.ORG>
  2837. Sender: jsq@usenix.ORG
  2838. Organization: Teltronics/TCT, Sarasota, FL
  2839. X-Submissions: std-unix@uunet.uu.net
  2840. Date: 20 Sep 90 12:53:46 GMT
  2841. Reply-To: std-unix@uunet.uu.net
  2842. To: std-unix@uunet.uu.net
  2843.  
  2844. Submitted-by: chip@tct.uucp (Chip Salzenberg)
  2845.  
  2846. According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
  2847. >The beauty and power of UNIX is the abstraction of files---
  2848. >not filesystems.
  2849.  
  2850. The filesystem means that anything worth reading or writing can be
  2851. accessed by a name in one large hierarchy.  It means a consistent
  2852. naming scheme.  It means that any entity can be opened, listed,
  2853. renamed or removed.
  2854.  
  2855. Both the filesystem and the file descriptor are powerful abstractions.
  2856. Do not make the mistake of minimizing either one's contribution to the
  2857. power and beauty of UNIX.
  2858. -- 
  2859. Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  2860.  
  2861. Volume-Number: Volume 21, Number 118
  2862.  
  2863. shar.1003.4.u.24121
  2864. echo 1003.4.v
  2865. cat >1003.4.v <<'shar.1003.4.v.24121'
  2866. From std-unix-request@uunet.uu.net  Thu Sep 20 14:20:46 1990
  2867. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2868.     id AA10926; Thu, 20 Sep 90 14:20:46 -0400
  2869. Posted-Date: 20 Sep 90 12:48:04 GMT
  2870. Received: by cs.utexas.edu (5.64/1.76) 
  2871. From: tct!chip@cs.utexas.edu (Chip Salzenberg)
  2872. Newsgroups: comp.std.unix
  2873. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2874. Message-Id: <529@usenix.ORG>
  2875. References: <488@usenix.ORG> <495@usenix.ORG> <523@usenix.ORG>
  2876. Sender: jsq@usenix.ORG
  2877. Organization: Teltronics/TCT, Sarasota, FL
  2878. X-Submissions: std-unix@uunet.uu.net
  2879. Date: 20 Sep 90 12:48:04 GMT
  2880. Reply-To: std-unix@uunet.uu.net
  2881. To: std-unix@uunet.uu.net
  2882.  
  2883. Submitted-by: chip@tct.uucp (Chip Salzenberg)
  2884.  
  2885. According to fouts@bozeman.bozeman.ingr (Martin Fouts):
  2886. >According to chip@tct.uucp (Chip Salzenberg):
  2887. >> Research Unix [...] put *more things [in the filesystem],
  2888. >> including processes (via the /proc pseudo-directory).
  2889. >
  2890. >The value of proc in the file system are debatable.  Certain debugging
  2891. >tools are easier to hang on an fcntl certain others are not.
  2892.  
  2893. With /proc, some things are much easier.  (Getting a list of all
  2894. active pids, for example.)  Nothing, however, is harder.  A big win.
  2895.  
  2896. >However, the presences of the proc file system is not a strong arguement
  2897. >for the inclusion of othere features in the file system.
  2898.  
  2899. I disagree.  I consider it an excellent example of how the designers
  2900. of Unix realize that all named objects potentially visible to more
  2901. than one process belong in the filesystem namespace.
  2902.  
  2903. >Unix programming has a history of using the filesystem for some things
  2904. >and not using it for others.  For example, I can demonstrate a
  2905. >semantic under which it is possible to put the time of day clock into
  2906. >the file system ...
  2907.  
  2908. Of course.  But in the absense of remotely mounted filesystems --
  2909. which V7 Unix was not designed to support -- there is only one time of
  2910. day, so it needs no name.  (I wouldn't be surprised if Plan 9 has a
  2911. /dev/timeofday, however.)
  2912.  
  2913. >... not all functions which might have been placed in the
  2914. >filesystem automatically have.
  2915.  
  2916. This observation is correct.  But it is clear that the designers of
  2917. Research Unix have used the filesystem for everything that needs a
  2918. name, and they continue to do so.  Their work asks, "Why have multiple
  2919. namespaces?"  Plan 9 asks the question again, and with a megaphone.
  2920.  
  2921. >Because of the way network connections are made, I have been
  2922. >convinced by networking experts (who are familiar with the "Unix
  2923. >style") that the filesystem namespace does not have a good semantic
  2924. >match for the network name space.
  2925.  
  2926. Carried to its logical conclusion, this argument would invalidate
  2927. special files and named pipes, since they also lack a "good semantic
  2928. match" with flat files.  In fact, the only entities with a "good
  2929. semantic match" for flat files are -- you guessed it -- flat files.
  2930.  
  2931. So, how do we program in such a system?  We use its elegant interface
  2932. -- or should I say "interfaces"?  Plain files, devices, IPCs, and
  2933. network connections each have a semantically accurate interface, which
  2934. unfortunately makes it different from all others.
  2935.  
  2936. This is progress?  "Forward into the past!"
  2937. -- 
  2938. Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  2939.  
  2940. Volume-Number: Volume 21, Number 119
  2941.  
  2942. shar.1003.4.v.24121
  2943. echo 1003.4.w
  2944. cat >1003.4.w <<'shar.1003.4.w.24121'
  2945. From std-unix-request@uunet.uu.net  Sun Sep 23 19:28:32 1990
  2946. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  2947.     id AA24302; Sun, 23 Sep 90 19:28:32 -0400
  2948. Posted-Date: 23 Sep 90 15:48:18 GMT
  2949. Received: by cs.utexas.edu (5.64/1.76) 
  2950. From: peter@ficc.ferranti.com (Peter da Silva)
  2951. Newsgroups: comp.std.unix
  2952. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  2953. Message-Id: <539@usenix.ORG>
  2954. References: <448@usenix.ORG> <457@usenix.ORG> <488@usenix.ORG> <495@usenix.ORG> <523@usenix.ORG>
  2955. Sender: jsq@usenix.ORG
  2956. Reply-To: peter@ficc.ferranti.com (Peter da Silva)
  2957. Organization: Xenix Support, FICC
  2958. X-Submissions: std-unix@uunet.uu.net
  2959. Date: 23 Sep 90 15:48:18 GMT
  2960. To: std-unix@uunet.uu.net
  2961.  
  2962. Submitted-by: peter@ficc.ferranti.com (Peter da Silva)
  2963.  
  2964. In article <523@usenix.ORG> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
  2965. > My aren't we superior.  (;-) At one time, I believed that sockets
  2966. > belonged in the filesystem name space.  I spent a long time arguing
  2967. > this point with members of the networking community before they
  2968. > convinced me that certain transient objects do not belong in that name
  2969. > space.  (See below)
  2970.  
  2971. You mean things that don't operate like a single bidirectional stream, like
  2972. pipes? It's funny that the sockets that *do* behave that way are not in the
  2973. file system, while UNIX-domain sockets (which have two ends on the local box)
  2974. are.
  2975.  
  2976. > Unix programming has a history of using the filesystem for some things
  2977. > and not using it for others.
  2978.  
  2979. UNIX programming has a history of using whatever ad-hoc hacks were needed
  2980. to get things working. It's full of evolutionary dead-ends... some of which
  2981. have been discarded (multiplexed files) and some of which have been patched
  2982. up and overloaded (file protection bits). But where things have moved closer
  2983. to the underlying principles (everything is a file, for example) it's become
  2984. the better for it.
  2985.  
  2986. > Sometimes there are objects which would be
  2987. > reasonable to treat with filesystem semantics for which there is no
  2988. > reasonable mechanism for introducing them into the filesystem name
  2989. > space.
  2990.  
  2991. This seems reasonable, but the rest is a pure argument from authority.
  2992. Could you repeat these arguments for the benefit of hose of us who don't
  2993. have the good fortune to know these networking experts you speak of?
  2994.  
  2995. [ Everyone involved in this discussion, please try to keep it in a
  2996. technical, not a personal, vein.  -mod ]
  2997.  
  2998. -- 
  2999. Peter da Silva.   `-_-'
  3000. +1 713 274 5180.   'U`
  3001. peter@ferranti.com
  3002.  
  3003. Volume-Number: Volume 21, Number 127
  3004.  
  3005. shar.1003.4.w.24121
  3006. echo 1003.4.x
  3007. cat >1003.4.x <<'shar.1003.4.x.24121'
  3008. From std-unix-request@uunet.uu.net  Tue Sep 25 10:37:08 1990
  3009. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3010.     id AA00719; Tue, 25 Sep 90 10:37:08 -0400
  3011. Posted-Date: 24 Sep 90 21:30:35 GMT
  3012. Received: by cs.utexas.edu (5.64/1.76) 
  3013. From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  3014. Newsgroups: comp.std.unix
  3015. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  3016. Message-Id: <540@usenix.ORG>
  3017. References: <523@usenix.ORG> <524@usenix.ORG> <528@usenix.ORG>
  3018. Sender: jsq@usenix.ORG
  3019. Organization: IR
  3020. X-Submissions: std-unix@uunet.uu.net
  3021. Date: 24 Sep 90 21:30:35 GMT
  3022. Reply-To: std-unix@uunet.uu.net
  3023. To: std-unix@uunet.uu.net
  3024.  
  3025. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  3026.  
  3027. In article <528@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
  3028. > According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
  3029. > >The beauty and power of UNIX is the abstraction of files---
  3030. > >not filesystems.
  3031. > Both the filesystem and the file descriptor are powerful abstractions.
  3032.  
  3033. On the contrary: Given file descriptors, the filesystem is an almost
  3034. useless abstraction.
  3035.  
  3036. Programs fall into two main classes. Some (such as diff) take a small,
  3037. fixed number of filename arguments and treat each one specially. They
  3038. become both simpler and more flexible if they instead use file
  3039. descriptors. I'll propose multitee as an example of this.
  3040.  
  3041. Others (such as sed or compress) take many filenames and perform some
  3042. action on each file in turn. They also become both simpler and more
  3043. flexible if they instead take input and output from a couple of file
  3044. descriptors, perhaps with a simple protocol for indicating file
  3045. boundaries. I'll propose the new version of filterfile as a
  3046. demonstration of how this can simplify application development.
  3047.  
  3048. In both cases, the application need know absolutely nothing about the
  3049. filesystem. A few utilities deal with filenames---shell redirection and
  3050. cat. A few utilities do the same for network connections---authtcp and
  3051. attachport. A few utilities do the same for pipes---the shell's piping.
  3052. But beyond these two or three programs per I/O object, the filesystem
  3053. contributes *nothing* to the vast majority of applications.
  3054.  
  3055. There is one notable exception. Some programs depend on reliable,
  3056. static, local or virtually local storage, usually for what amounts to
  3057. interprocess communication. (login needs /etc/passwd. cron reads crontab.
  3058. And so on.) This is exactly what filesystems were designed for, and a
  3059. program that wants reliable, static, local storage is perfectly within
  3060. its rights to demand the sensible abstraction we call a filesystem.
  3061.  
  3062. Most applications that use input and output, though, don't care that
  3063. it's reliable or static or local. For them, the filesystem is pointless.
  3064. Many of us are convinced that open() and rename() and unlink() and so on
  3065. are an extremely poor match for unreliable or dynamic or remote I/O. We
  3066. also see the sheer uselessness of forcing all I/O into the filesystem.
  3067. You must convince us that open() makes sense for everything that might
  3068. be a file descriptor, and that it provides a real benefit for future
  3069. applications, before you destroy what we see as the beauty and power of
  3070. UNIX.
  3071.  
  3072. ---Dan
  3073.  
  3074. Volume-Number: Volume 21, Number 128
  3075.  
  3076. shar.1003.4.x.24121
  3077. echo 1003.4.y
  3078. cat >1003.4.y <<'shar.1003.4.y.24121'
  3079. From std-unix-request@uunet.uu.net  Tue Sep 25 10:20:43 1990
  3080. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3081.     id AA24327; Tue, 25 Sep 90 10:20:43 -0400
  3082. Posted-Date: 24 Sep 90 21:40:07 GMT
  3083. Received: by cs.utexas.edu (5.64/1.76) 
  3084. From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  3085. Newsgroups: comp.std.unix
  3086. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  3087. Message-Id: <541@usenix.ORG>
  3088. References: <495@usenix.ORG> <523@usenix.ORG> <539@usenix.ORG>
  3089. Sender: jsq@usenix.ORG
  3090. Organization: IR
  3091. X-Submissions: std-unix@uunet.uu.net
  3092. Date: 24 Sep 90 21:40:07 GMT
  3093. Reply-To: std-unix@uunet.uu.net
  3094. To: std-unix@uunet.uu.net
  3095.  
  3096. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  3097.  
  3098. In article <539@usenix.ORG> peter@ficc.ferranti.com (Peter da Silva) writes:
  3099. > But where things have moved closer
  3100. > to the underlying principles (everything is a file, for example) it's become
  3101. > the better for it.
  3102.  
  3103. The underlying principle is that everything is a file *descriptor*.
  3104.  
  3105. > > Sometimes there are objects which would be
  3106. > > reasonable to treat with filesystem semantics for which there is no
  3107. > > reasonable mechanism for introducing them into the filesystem name
  3108. > > space.
  3109. > This seems reasonable, but the rest is a pure argument from authority.
  3110. > Could you repeat these arguments for the benefit of hose of us who don't
  3111. > have the good fortune to know these networking experts you speak of?
  3112.  
  3113. The filesystem fails to deal with many (most?) types of I/O that aren't
  3114. reliable, static, and local. Here's an example: In reality, you initiate
  3115. a network stream connection in two stages. First you send off a request,
  3116. which wends its way through the network. *Some time later*, the response
  3117. arrives. Even if you aren't doing a three-way handshake, you must wait a
  3118. long time (in practice, up to several seconds on the Internet) before
  3119. you know whether the open succeeds.
  3120.  
  3121. In the filesystem abstraction, you open a filename in one stage. You
  3122. can't do anything between initiating the open and finding out whether or
  3123. not it succeeds. This just doesn't match reality, and it places a huge
  3124. restriction on programs that want to do something else while they
  3125. communicate.
  3126.  
  3127. You can easily construct other examples, but one should be enough to
  3128. convince you that open() just isn't sufficiently general for everything
  3129. that you might read() or write().
  3130.  
  3131. ---Dan
  3132.  
  3133. Volume-Number: Volume 21, Number 129
  3134.  
  3135. shar.1003.4.y.24121
  3136. echo 1003.4.z
  3137. cat >1003.4.z <<'shar.1003.4.z.24121'
  3138. From std-unix-request@uunet.uu.net  Tue Sep 25 16:34:14 1990
  3139. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3140.     id AA16616; Tue, 25 Sep 90 16:34:14 -0400
  3141. Posted-Date: 25 Sep 90 16:44:28 GMT
  3142. Received: by cs.utexas.edu (5.64/1.76) 
  3143. From: henry@zoo.toronto.edu (Henry Spencer)
  3144. Newsgroups: comp.std.unix
  3145. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  3146. Message-Id: <543@usenix.ORG>
  3147. References: <495@usenix.ORG> <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG>
  3148. Sender: jsq@usenix.ORG
  3149. Organization: U of Toronto Zoology
  3150. X-Submissions: std-unix@uunet.uu.net
  3151. Date: 25 Sep 90 16:44:28 GMT
  3152. Reply-To: std-unix@uunet.uu.net
  3153. To: std-unix@uunet.uu.net
  3154.  
  3155. Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
  3156.  
  3157. In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  3158. >In the filesystem abstraction, you open a filename in one stage. You
  3159. >can't do anything between initiating the open and finding out whether or
  3160. >not it succeeds. This just doesn't match reality, and it places a huge
  3161. >restriction on programs that want to do something else while they
  3162. >communicate.
  3163.  
  3164. Programs that want to do two things at once should use explicit parallelism,
  3165. e.g. some sort of threads facility.  In every case I've seen, this yielded
  3166. vastly superior code, with clearer structure and better error handling.
  3167. -- 
  3168. TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
  3169. OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry
  3170.  
  3171. Volume-Number: Volume 21, Number 131
  3172.  
  3173. shar.1003.4.z.24121
  3174. echo 1003.5.a
  3175. cat >1003.5.a <<'shar.1003.5.a.24121'
  3176. From std-unix-request@uunet.uu.net  Mon Sep 17 20:25:12 1990
  3177. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3178.     id AA26016; Mon, 17 Sep 90 20:25:12 -0400
  3179. Posted-Date: 17 Sep 90 19:58:52 GMT
  3180. Received: by cs.utexas.edu (5.64/1.76) 
  3181. From: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
  3182. Newsgroups: comp.std.unix
  3183. Subject: Re: Standards Update, IEEE 1003.5: Ada bindings
  3184. Message-Id: <522@usenix.ORG>
  3185. References: <521@usenix.ORG>
  3186. Sender: jsq@usenix.ORG
  3187. Reply-To: randall@Virginia.EDU (Ran Atkinson)
  3188. Organization: University of Virginia
  3189. X-Submissions: std-unix@uunet.uu.net
  3190. Date: 17 Sep 90 19:58:52 GMT
  3191. To: std-unix@uunet.uu.net
  3192.  
  3193. Submitted-by: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
  3194.  
  3195. The comment in the snitch report about the committee "knowing" that
  3196. 30 days being insufficient time to review the P1003.5 draft is distressing.
  3197.  
  3198. Indeed I am one of the folks who is going to try to review the draft and
  3199. 30 days is no where near enough time to do a proper job.  The notion of
  3200. starting at different places is NOT helpful because it is likely that my
  3201. objections won't be evenly distributed across the document and because any
  3202. I miss for lack of time can't be raised in a future ballot.
  3203.  
  3204. The TCOS administration should REQUIRE that balloting groups be given
  3205. sufficient time to review documents thoroughly.  Otherwise we will end
  3206. up with incompletely reviewed standards which we will then have to try
  3207. to live with.
  3208.  
  3209. This just serves to reinforce my view that the POSIX effort has changed
  3210. from standardising existing practice with due deliberation to one to
  3211. create as many standards documents as possible as quickly as possible
  3212. without due regard for existing practice or internal consistency among
  3213. the various documents that are under P1003.
  3214.  
  3215. Standards are a good thing if done carefully.  I'm concerned that the
  3216. POSIX effort is moving too hastily to be truly useful to us users.
  3217.  
  3218. Randall Atkinson
  3219. randall@Virginia.EDU
  3220.  
  3221. Volume-Number: Volume 21, Number 113
  3222.  
  3223. shar.1003.5.a.24121
  3224. echo 1003.5.b
  3225. cat >1003.5.b <<'shar.1003.5.b.24121'
  3226. From std-unix-request@uunet.uu.net  Wed Sep 19 18:25:12 1990
  3227. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3228.     id AA24407; Wed, 19 Sep 90 18:25:12 -0400
  3229. Posted-Date: 19 Sep 90 17:09:18 GMT
  3230. Received: by cs.utexas.edu (5.64/1.76) 
  3231. From: arnold%audiofax.com@mathcs.emory.edu (Arnold Robbins)
  3232. Newsgroups: comp.std.unix
  3233. Subject: Balloting times (was: Re: Standards Update, IEEE 1003.5: Ada bindings)
  3234. Message-Id: <526@usenix.ORG>
  3235. References: <521@usenix.ORG> <522@usenix.ORG>
  3236. Sender: jsq@usenix.ORG
  3237. Reply-To: arnold@audiofax.com
  3238. Organization: AudioFAX Inc., Atlanta
  3239. X-Submissions: std-unix@uunet.uu.net
  3240. Date: 19 Sep 90 17:09:18 GMT
  3241. To: std-unix@uunet.uu.net
  3242.  
  3243. Submitted-by: arnold%audiofax.com@mathcs.emory.edu (Arnold Robbins)
  3244.  
  3245. In article <522@usenix.ORG> randall@Virginia.EDU (Ran Atkinson) writes:
  3246. >Indeed I am one of the folks who is going to try to review the draft and
  3247. >30 days is no where near enough time to do a proper job.
  3248.  
  3249. Let me second this with a very loud, resounding "Amen!".  The 1003.2 drafts
  3250. are *huge*.  A month to go through them is just silly.  I did a lousy job
  3251. on the last one, just because of a lack of time.
  3252. -- 
  3253. Arnold Robbins                AudioFAX, Inc. | Laundry increases
  3254. 2000 Powers Ferry Road, #200 / Marietta, GA. 30067     | exponentially in the
  3255. INTERNET: arnold@audiofax.com Phone:   +1 404 933 7600 | number of children.
  3256. UUCP:      emory!audfax!arnold Fax-box: +1 404 618 4581 |   -- Miriam Robbins
  3257.  
  3258. Volume-Number: Volume 21, Number 117
  3259.  
  3260. shar.1003.5.b.24121
  3261. echo bof.a
  3262. cat >bof.a <<'shar.bof.a.24121'
  3263. From std-unix-request@uunet.uu.net  Thu Aug 23 15:19:23 1990
  3264. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3265.     id AA29203; Thu, 23 Aug 90 15:19:23 -0400
  3266. Posted-Date: 22 Aug 90 00:17:46 GMT
  3267. Received: by cs.utexas.edu (5.64/1.71)
  3268.     id AA22661; Thu, 23 Aug 90 14:19:19 -0500
  3269. From: calvin!sws@cs.utexas.edu (Susanne Smith)
  3270. Newsgroups: comp.std.unix
  3271. Subject: Re: Standards Update, USENIX Standards BOF
  3272. Message-Id: <454@usenix.ORG>
  3273. References: <434@usenix.ORG>
  3274. Sender: std-unix@usenix.ORG
  3275. X-Submissions: std-unix@uunet.uu.net
  3276. Date: 22 Aug 90 00:17:46 GMT
  3277. Reply-To: std-unix@uunet.uu.net
  3278. To: std-unix@uunet.uu.net
  3279.  
  3280. From:  sws@calvin.uucp (Susanne Smith)
  3281.  
  3282. >2.  Opinion polling
  3283. >
  3284. >      John tried to discern whether attendees thought they were being
  3285. >      well-served by John, the USENIX Standards Watchdog Committee,
  3286. >      and the USENIX position on standards: to attempt to prevent
  3287. >      standards from prohibiting innovation.  Indeed, at Snowbird, the
  3288. >      site of the April POSIX meeting, John was told that smaller
  3289. >      companies don't like our participation because of this position.
  3290. >      Think about this a while.  (For a more detailed discussion of
  3291. >      the USENIX position on standards, see either ;login: 15(3):25 or
  3292. >      the periodic overview posting in comp.std.unix about the USENIX
  3293. >      Standards Watchdog Committee.)
  3294. >
  3295. >      John explained how USENIX came to its current policies and why
  3296. >      it does not endorse standards of its own.  Some audience members
  3297. >      were unhappy with extant standards bodies and said they wouldn't
  3298. >      mind if USENIX played a more active role.  Susanne reminded us
  3299. >      that UniForum working groups, which she praised, play such a
  3300. >      role.
  3301.  
  3302. What I remember about this portion of the bof is a little bit different.
  3303. John had been talking about the new procedures developed by the TCOS 
  3304. (IEEE Computer Society Technical Committee on Operating Systems)
  3305. SEC (Standards Executive Committee) to limit the proliferation of 
  3306. standards groups and to make sure that groups in existence 
  3307. made acceptable progress (see Volume 19, Number 97). The question was 
  3308. asked as to what other forums are available for groups that do not gain 
  3309. SEC approval.  The UniForum Technical Committees were mentioned as one 
  3310. forum for work that might be premature or inappropriate for TCOS.
  3311.  
  3312.  
  3313.  
  3314.  
  3315.  
  3316.  
  3317.  
  3318.  
  3319.  
  3320.  
  3321.  
  3322.  
  3323.  
  3324.  
  3325.  
  3326.  
  3327.  
  3328.  
  3329.  
  3330.  
  3331.  
  3332.  
  3333.  
  3334. Volume-Number: Volume 21, Number 55
  3335.  
  3336. shar.bof.a.24121
  3337. echo nist.a
  3338. cat >nist.a <<'shar.nist.a.24121'
  3339. From std-unix-request@uunet.uu.net  Fri Sep 28 21:22:12 1990
  3340. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3341.     id AA03871; Fri, 28 Sep 90 21:22:12 -0400
  3342. Posted-Date: 28 Sep 90 19:27:10 GMT
  3343. Received: by cs.utexas.edu (5.64/1.76) 
  3344. From: gwyn@smoke.brl.mil (Doug Gwyn)
  3345. Newsgroups: comp.std.unix
  3346. Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
  3347. Message-Id: <560@usenix.ORG>
  3348. References: <558@usenix.ORG>
  3349. Sender: jsq@usenix.ORG
  3350. Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
  3351. X-Submissions: std-unix@uunet.uu.net
  3352. Date: 28 Sep 90 19:27:10 GMT
  3353. Reply-To: std-unix@uunet.uu.net
  3354. To: std-unix@uunet.uu.net
  3355.  
  3356. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  3357.  
  3358. In article <558@usenix.ORG> std-unix@uunet.uu.net writes:
  3359. >Standards let the government avoid vendor-specific requirements like
  3360. >UNIX or SVID.  ...
  3361. >The Government has a burning need for a standard, they find it
  3362. >politically unacceptable to use UNIX System V as that standard, ...
  3363.  
  3364. I have to challenge this often-heard (from DEC, for example, who don't
  3365. want truly open systems in the first place) rationale.  In fact there
  3366. have been more than one major (in the billion-dollar range) federal
  3367. acquisition where SVID conformance was specified, and that specification
  3368. was successfully upheld in appeals.  Thus the government's official
  3369. position would appear to be that SVID is an acceptable standard.
  3370.  
  3371. Note that SVID is not the same as AT&T UNIX System V implementation,
  3372. although there is clearly a relationship between them.  (But there
  3373. also is between UNIX System V and POSIX, ANSI C, etc.)
  3374.  
  3375. Volume-Number: Volume 21, Number 148
  3376.  
  3377. shar.nist.a.24121
  3378. echo nist.b
  3379. cat >nist.b <<'shar.nist.b.24121'
  3380. From std-unix-request@uunet.uu.net  Fri Sep 28 21:22:20 1990
  3381. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3382.     id AA03945; Fri, 28 Sep 90 21:22:20 -0400
  3383. Posted-Date: 28 Sep 90 23:49:05 GMT
  3384. Received: by cs.utexas.edu (5.64/1.76) 
  3385. From: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
  3386. Newsgroups: comp.std.unix
  3387. Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
  3388. Message-Id: <561@usenix.ORG>
  3389. References: <558@usenix.ORG>
  3390. Sender: jsq@usenix.ORG
  3391. Reply-To: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
  3392. Organization: University of Virginia
  3393. X-Submissions: std-unix@uunet.uu.net
  3394. Date: 28 Sep 90 23:49:05 GMT
  3395. To: std-unix@uunet.uu.net
  3396.  
  3397. Submitted-by: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
  3398.  
  3399. As a former Federal employee and someone who looks at POSIX
  3400. strictly from the user point of view, I'd much rather see NIST
  3401. write a FIPS based on P1003.2/10 AND the current P1003.2a than
  3402. to have them write one based on P1003.2/9 because it seems clear
  3403. that draft 9 will be farther from the end product than draft 10
  3404. will be by a significant margin and P1003.2a has a lot of stuff 
  3405. that most existing UNIX (tm) users expect to see that was omitted
  3406. from P1003.2.  For that matter, it might be worth looking at the
  3407. SVID for System V, Release 4 and the BSD 4.3 Tahoe documentation
  3408. to see if there is other stuff that isn't part of the P1003.2 
  3409. effort that NIST thinks government users need.  For my part,
  3410. I want P1003.2 to specify an environment with capabilties
  3411. comparable to what BSD and the SVID both specify and I don't
  3412. really see that just now in the drafts.
  3413.  
  3414. I have mixed feelings about the notion of NIST pushing the FIPS this fast, 
  3415. but I agree that some vendors are clearly just trying to drag out the
  3416. IEEE standards process and are trying to water down the standard so
  3417. that their existing proprietary system will meet the standard.
  3418.  
  3419. Randall Atkinson
  3420. randall@Virginia.EDU
  3421.  
  3422. Volume-Number: Volume 21, Number 149
  3423.  
  3424. shar.nist.b.24121
  3425. echo nist.c
  3426. cat >nist.c <<'shar.nist.c.24121'
  3427. From std-unix-request@uunet.uu.net  Mon Oct  1 14:33:19 1990
  3428. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3429.     id AA03094; Mon, 1 Oct 90 14:33:19 -0400
  3430. Posted-Date: 1 Oct 90 15:50:25 GMT
  3431. Received: by cs.utexas.edu (5.64/1.76) 
  3432. From: vyw@stc06.ctd.ornl.gov (WHITE V L)
  3433. Newsgroups: comp.std.unix
  3434. Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
  3435. Message-Id: <567@usenix.ORG>
  3436. Sender: jsq@usenix.ORG
  3437. Subject-References: <558@usenix.ORG> <560@usenix.ORG>
  3438. X-Submissions: std-unix@uunet.uu.net
  3439. Date: 1 Oct 90 15:50:25 GMT
  3440. Reply-To: std-unix@uunet.uu.net
  3441. To: std-unix@uunet.uu.net
  3442.  
  3443. Submitted-by: vyw@stc06.ctd.ornl.gov (WHITE V L)
  3444.  
  3445. Doug Gwyn writes: 
  3446.  
  3447.     >In article <558@usenix.ORG> std-unix@uunet.uu.net writes:
  3448.     >>Standards let the government avoid vendor-specific requirements like
  3449.     >>UNIX or SVID.  ...
  3450.     >>The Government has a burning need for a standard, they find it
  3451.     >>politically unacceptable to use UNIX System V as that standard, ...
  3452.     >
  3453.     >I have to challenge this often-heard (from DEC, for example, who don't
  3454.     >want truly open systems in the first place) rationale.  In fact there
  3455.     >have been more than one major (in the billion-dollar range) federal
  3456.     >acquisition where SVID conformance was specified, and that specification
  3457.     >was successfully upheld in appeals.  Thus the government's official
  3458.     >position would appear to be that SVID is an acceptable standard.
  3459.  
  3460. Yes and no.  This is hard to explain to someone who hasn't lived through it.
  3461. Yes, the 3.5 billion dollar AFCAC case upheld the legality of the use of
  3462. the SVID in procurements.  No, SVID is not proprietary and any vendor
  3463. who wished could make his system conform to it.  Yes, the SVID is a perfectly
  3464. good standard and we could be using it to fill in the gaps in our
  3465. procurement specs until the IEEE has time to produce a reasonable and
  3466. mature set of Posix standards.
  3467.  
  3468. So why aren't we? 
  3469.  
  3470. One reason is that we don't want to lock out systems that are primarily
  3471. Berkeley based.  However, we could still pull out enough definitions from 
  3472. the SVID for utilities which don't differ any or much from their BSD 
  3473. equivalents, write out exceptions to allow for the BSD differences,
  3474. and have a decent spec which would get us a Unix (not a proprietary) system.
  3475.  
  3476. The bigger reason is that "SVID" is a four letter word to the federal 
  3477. supervisors who are pressured by vendors hinting darkly at protests. 
  3478. The AFCAC precedent doesn't stop these threats, and it doesn't matter whether 
  3479. the vendor could actually win one of these protests.  
  3480. Any protest, whether it is eventually upheld or not, adds an incredible
  3481. burden of time, money, and headaches to the already baroque procurement
  3482. process.  It can stop your buy for months.  The problem is
  3483. the vendors who have had a free reign in the government for so many years and
  3484. aren't willing to give up their hold now that
  3485. they are being forced to play by the rules of competitive procurement.  
  3486. I suppose the problem is also the system that lets them clog the works with 
  3487. unjustified protests, but I don't know how to prevent that without being 
  3488. unfair to the vendors who have justified protests.
  3489.  
  3490. I've been told this is no excuse to pressure the longsuffering Roger Martin
  3491. to hurry through an immature FIPS and that I should just write a better spec,
  3492. good grief. Just say what I want.  That's my job, after all.
  3493. Well, I have done that, because I had to, and I ask you, how am I
  3494. to define what shell or editor or grep I want without reference to
  3495. SVID or the BSD manual or X/OPEN or some draft of 1003.2 (to which I am
  3496. reminded on every page not to require conformance)?  Somebody has a complaint 
  3497. about all of them, and I've wasted a lot of time bending words to satisfy
  3498. nervous bosses when I'd rather be programming.  
  3499.  
  3500. Yes, we should make the standards process reasonable and not rush it.
  3501. Yes, we'll have to make some sacrifices in lost productivity in the meantime
  3502. in order to accomplish that goal.  It would help a lot if the vendors
  3503. meant what they said about their standards support instead of standing
  3504. in the way.  And you know, I've used the products of those vendors who
  3505. are making the most noise, and they're GOOD.  Don't they believe that
  3506. themselves?  Don't they think their products can stand on their own merits?
  3507. Why are they so afraid of the big bad SVID?
  3508.  
  3509. I'm sorry this is a nontechnical contribution, and a long one at that,
  3510. but unfortunately the
  3511. nontechnical problems sometimes have a greater impact on our work and
  3512. are more difficult to overcome than the technical ones.
  3513.  
  3514. These opinions are wholely mine and do not represent an official position
  3515. of my employers or of the federal government.
  3516.  
  3517. Vicky White
  3518. Oak Ridge National Laboratory
  3519. vyw@ornl.gov
  3520.  
  3521. Volume-Number: Volume 21, Number 159
  3522.  
  3523. shar.nist.c.24121
  3524. echo nist.d
  3525. cat >nist.d <<'shar.nist.d.24121'
  3526. From std-unix-request@uunet.uu.net  Mon Oct  1 14:30:23 1990
  3527. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3528.     id AA01767; Mon, 1 Oct 90 14:30:23 -0400
  3529. Posted-Date: 1 Oct 90 17:56:00 GMT
  3530. Received: by cs.utexas.edu (5.64/1.76) 
  3531. From: hl.rogers@ncrcae.Columbia.NCR.COM (HL Rogers)
  3532. Newsgroups: comp.std.unix
  3533. Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
  3534. Message-Id: <107019@uunet.UU.NET>
  3535. References: <558@usenix.ORG>
  3536. Sender: jsq@uunet.uu.net
  3537. Reply-To: hl.rogers@ncrcae.Columbia.NCR.COM (HL Rogers)
  3538. Organization: NCR E&M Columbia, Columbia, SC
  3539. X-Submissions: std-unix@uunet.uu.net
  3540. Date: 1 Oct 90 17:56:00 GMT
  3541. To: std-unix@uunet.uu.net
  3542.  
  3543. Submitted-by: rogers@ofc.uucp
  3544.  
  3545. In article <558@usenix.ORG> std-unix@uunet.uu.net writes:
  3546. >
  3547. >In my opinion, NIST is going to go ahead and publish a flawed FIPS in
  3548. >the belief that it will drive the IEEE to pick up the pace of POSIX.
  3549. >The Government has a burning need for a standard, they find it
  3550. >politically unacceptable to use UNIX System V as that standard, and
  3551. >they strongly prefer action over waiting for the IEEE.
  3552. >
  3553. There is something to be said for any action which motivates the IEEE
  3554. committees to move a little faster.  This type of action, however, will
  3555. ultimately cost the taxpayer when agencies who purchase D9 implementations
  3556. have to retool a year later because all the developed applications will
  3557. honor the final dot 2 draft.
  3558.  
  3559. What I fail to understand is IEEE's continuing propensity to violate the
  3560. "prime directive", i.e., their failure to specify common practice.  As 
  3561. long as they continue this annoying habit, they will continue creating 
  3562. these problems.  It is far better to specify common practice, then work 
  3563. through some other forum on getting the vendors to change the functionality 
  3564. for future versions.
  3565.  
  3566. Attempting to legislate change through IEEE dot n committees may even
  3567. work, but guess what?  Instead of Uncle Sam buying something off the
  3568. shelf for near commodity prices, he has to buy a "special" for inflated
  3569. prices because it had to be especially developed.  Nobody had it, not 
  3570. common practice,...  And guess what else?  You, I, Roger Martin, and
  3571. the rest of us collectively make up "Uncle Sam."  It's your money, ace.
  3572.  
  3573. IMHO, IEEE "management" needs to put their foot down and put an end to
  3574. the real political battles - those being fought in IEEE dot n 
  3575. committees.  Then NIST would be an ally instead of an opponent.
  3576. ---
  3577. HL Rogers    (hl.rogers@ncrcae.Columbia.NCR.COM)
  3578.  
  3579. Volume-Number: Volume 21, Number 160
  3580.  
  3581. shar.nist.d.24121
  3582. echo nist.e
  3583. cat >nist.e <<'shar.nist.e.24121'
  3584. From jsq@cs.utexas.edu  Wed Oct  3 08:58:59 1990
  3585. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3586.     id AA02719; Wed, 3 Oct 90 08:58:59 -0400
  3587. Posted-Date: 3 Oct 90 10:06:10 GMT
  3588. Received: by cs.utexas.edu (5.64/1.76) 
  3589. From: domo@tsa.co.uk (Dominic Dunlop)
  3590. Newsgroups: comp.std.unix
  3591. Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
  3592. Message-Id: <13137@cs.utexas.edu>
  3593. References: <558@usenix.ORG> <107019@uunet.UU.NET>
  3594. Sender: jsq@cs.utexas.edu
  3595. Reply-To: domo@tsa.co.uk
  3596. Organization: The Standard Answer Ltd.
  3597. X-Submissions: std-unix@uunet.uu.net
  3598. Date: 3 Oct 90 10:06:10 GMT
  3599. To: std-unix@uunet.uu.net
  3600.  
  3601. Submitted-by: domo@tsa.co.uk (Dominic Dunlop)
  3602.  
  3603. In article <107019@uunet.UU.NET> hl.rogers@ncrcae.Columbia.NCR.COM
  3604. (HL Rogers) writes:
  3605. > There is something to be said for any action which motivates the IEEE
  3606. > committees to move a little faster.  This type of action, however, will
  3607. > ultimately cost the taxpayer when agencies who purchase D9 implementations
  3608. > have to retool a year later because all the developed applications will
  3609. > honor the final dot 2 draft.
  3610.  
  3611. While we can wish for an ideal world where standards committees are
  3612. always able quickly to reach a broad consensus based on well-tried
  3613. existing practice, and can deliver a well-rounded document to an
  3614. accepting and grateful public, we have to concern ourself with real
  3615. life.
  3616.  
  3617. Real life is populated by engineers with a variety of opinions,
  3618. politicians, lawyers, accountants, and, if you're unlucky, people
  3619. waving guns -- all forces which make it more difficult to achieve what
  3620. may appear to you to be obvious goals.  Like you, I, and Uncle Sam,
  3621. they're just doing their jobs, and may consider different goals to be
  3622. obvious.  One just has to evaluate how well one is doing despite their
  3623. malign influence.
  3624.  
  3625. And I think that requiring conformance to a draft standard is a whole
  3626. lot better than not requiring conformance to anything in particular.
  3627. Sure, it will be annoying and painful to convert later when the real
  3628. thing comes along.  And it will cost real money.  But it will cost a
  3629. whole lot less money in total than -- say -- implementing using a
  3630. proprietary environment now, and switching to an official POSIX.2 when
  3631. it comes along.  Yes, the up-front costs may be higher because a draft
  3632. 9-conforming environment is likely to be more or less custom-built (or
  3633. at least, suppliers are liable to try to stick you for the costs of a
  3634. fully custom job, even if such costs are not justified).  But the
  3635. downstream costs, including the costs of any draft-to-final conversion,
  3636. are likely to be way lower.
  3637. -- 
  3638. Dominic Dunlop
  3639.  
  3640. Volume-Number: Volume 21, Number 173
  3641.  
  3642. shar.nist.e.24121
  3643. echo nist.f
  3644. cat >nist.f <<'shar.nist.f.24121'
  3645. From std-unix-request@uunet.uu.net  Sat Oct  6 17:17:29 1990
  3646. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3647.     id AA04337; Sat, 6 Oct 90 17:17:29 -0400
  3648. Posted-Date: 6 Oct 90 14:43:47 GMT
  3649. Received: by cs.utexas.edu (5.64/1.77) 
  3650. From: ahby@bungia.bungia.mn.org (Shane P. McCarron)
  3651. Newsgroups: comp.std.unix
  3652. Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
  3653. Message-Id: <13272@cs.utexas.edu>
  3654. References: <558@usenix.ORG> <107019@uunet.UU.NET> <13137@cs.utexas.edu>
  3655. Sender: fletcher@cs.utexas.edu
  3656. Organization: Bugoslavian Embassy, St. Paul, MN
  3657. X-Submissions: std-unix@uunet.uu.net
  3658. Date: 6 Oct 90 14:43:47 GMT
  3659. Reply-To: std-unix@uunet.uu.net
  3660. To: std-unix@uunet.uu.net
  3661.  
  3662. Submitted-by: ahby@bungia.bungia.mn.org (Shane P. McCarron)
  3663.  
  3664. In article <13137@cs.utexas.edu> domo@tsa.co.uk writes:
  3665. >Submitted-by: domo@tsa.co.uk (Dominic Dunlop)
  3666. >
  3667. >While we can wish for an ideal world where standards committees are
  3668. >always able quickly to reach a broad consensus based on well-tried
  3669. >existing practice, and can deliver a well-rounded document to an
  3670. >accepting and grateful public, we have to concern ourself with real
  3671. >life.
  3672.  
  3673. Dominic says that we have to concern ourselves with real life.  Real life 
  3674. is that POSIX.2 Draft 9 is an immature document.  Making it a
  3675. procurement specification means that system vendors will have to do a
  3676. lot of work that they will, to some extent, just throw away later.
  3677. Moreover, this work will be duplicated by every system vendor wanting
  3678. to sell into that market.  Also, since there are organizations like
  3679. the Open Software Foundation and UNIX System Laboratories producing
  3680. reference implementations of the operating system, these vendors could
  3681. have not done the work themselves at all!
  3682.  
  3683. This economy is development is something that must be taken into
  3684. account by the US government, and in fact by any organization
  3685. specifying procurement requirements.  These organizations want to
  3686. procure something TODAY!  They want it to look like a standard
  3687. implementation, but they would probably be just as happy if the
  3688. applications that they really need ran.  MS-DOS is not a standard, but
  3689. it runs flight-simulator and Lotus.  That's enough for most people.
  3690.  
  3691. What we, as people involved in the standardization process, have to do
  3692. is work with the Federal government and other organizations to help
  3693. them understand the folly of prematurely pointing to standards.  Those
  3694. standards are, for the most part, build upon existing practice.  When
  3695. organizations go to put together a procurement specification, they
  3696. need to know what components of that standard are stable and represent
  3697. existing practice that is available to them TODAY.  If they use that
  3698. as the basis of their procurement they will have an Open Systems
  3699. solution that they can actually get their hands on.  Further, that
  3700. solution will be upwardly compatible with the final standard because
  3701. it is a proper subset of the functionality in that standard.
  3702.  
  3703. A example of reasonable subsetting from Draft 9 would be system limits
  3704. like LINEMAX.  In POSIX.2 this is specified as being something like
  3705. 4k (I can't remember).  Anyway, the limit is supposed to apply to any
  3706. utility that reads lines of input from the user or from text files.
  3707. No system in the world that is shipping today supports this limit in
  3708. every system utility.  It is an ideal goal that the companies represented 
  3709. by the participants in POSIX.2 have agreed to move to over time.  Producing 
  3710. a standard is just that: an agreement that all of "this" existing practice 
  3711. is pretty good, and here are the areas in which we agree that it should be
  3712. better defined or enhanced to make the functionality maximally
  3713. advantageous for application developers and end users.  This is a very
  3714. important point, and tends to be lost on casual observers of
  3715. standardization efforts.
  3716.  
  3717. >And I think that requiring conformance to a draft standard is a whole
  3718. >lot better than not requiring conformance to anything in particular.
  3719. >Sure, it will be annoying and painful to convert later when the real
  3720. >thing comes along.  And it will cost real money.  But it will cost a
  3721. >whole lot less money in total than -- say -- implementing using a
  3722. >proprietary environment now, and switching to an official POSIX.2 when
  3723. >it comes along.  Yes, the up-front costs may be higher because a draft
  3724. >9-conforming environment is likely to be more or less custom-built (or
  3725. >at least, suppliers are liable to try to stick you for the costs of a
  3726. >fully custom job, even if such costs are not justified).  But the
  3727. >downstream costs, including the costs of any draft-to-final conversion,
  3728. >are likely to be way lower.
  3729.  
  3730. Well, it depends.  The cost to the system vendor will be lower, but
  3731. not to the end user.  Any functionality that user took advantage of
  3732. that was not represented in the final standard will suddenly become
  3733. non-portable.  Worse yet, it may become unavailable.  From a system
  3734. vendors perspective, they may have to support some strange
  3735. functioanlity or system limits because the draft standard required
  3736. them to, some agency took advantage of it, and now they are stuck.
  3737. They have to support thios non-portable functionality forever, as well
  3738. as the real standard.  This is not at all the goal of standardization,
  3739. and should not be the goal of the agencies procuring systems.
  3740.  
  3741. Standing on my soap-box again for a minute, we have to keep the
  3742. overall goal of open systems in sight.  That goal is that the
  3743. application developers of the world are given a guaranteed base on
  3744. which they can develop portable applications that can interoperate
  3745. with one another.  This means having a steady functional migration
  3746. which NEVER capriciously breaks compatability.  This may mean that in
  3747. the short term new, exciting functionality is not introduced to the
  3748. disadvantage of existing practice.  This is the price we pay for
  3749. keeping the application developers interested in open systems.  The
  3750. personal productivity application base is just coming available for
  3751. open systems platforms in ways that are attractive to the casual
  3752. computer user.  We CANNOT abdicate our responsibility to retain that
  3753. extremely hard-won base of applications by allowing radical change in the
  3754. definition of the system.  If we do that, we might as well go and buy DOS.
  3755.  
  3756. Shane P. McCarron
  3757. Secretary, IEEE TCOS-SS
  3758. -- 
  3759. Shane P. McCarron                Phone: +1 612-224-9239
  3760. Project Manager                    Internet: ahby@bungia.mn.org
  3761.  
  3762.  
  3763. Volume-Number: Volume 21, Number 189
  3764.  
  3765. shar.nist.f.24121
  3766. echo overview.a
  3767. cat >overview.a <<'shar.overview.a.24121'
  3768. From std-unix-request@uunet.uu.net  Fri Oct 12 14:18:50 1990
  3769. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3770.     id AA03515; Fri, 12 Oct 90 14:18:50 -0400
  3771. Posted-Date: 12 Oct 90 14:55:22 GMT
  3772. Received: by cs.utexas.edu (5.64/1.78) 
  3773. From: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
  3774. Newsgroups: comp.std.unix
  3775. Subject: Re: Internationalisation
  3776. Message-Id: <13523@cs.utexas.edu>
  3777. References: <13501@cs.utexas.edu>
  3778. Sender: fletcher@cs.utexas.edu
  3779. Reply-To: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
  3780. Organization: University of Virginia
  3781. X-Submissions: std-unix@uunet.uu.net
  3782. Date: 12 Oct 90 14:55:22 GMT
  3783. To: std-unix@uunet.uu.net
  3784.  
  3785. Submitted-by: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
  3786.  
  3787. While I am fond of Vietnamese, I'd like to suggest that it not be
  3788. used in future examples of internationalisation for several reasons
  3789. including the lack of a defined character set standard for Vietnamese.
  3790.  
  3791. A number of people, including me, were trying to come up with a reasonable
  3792. modification of the ISO 8859/1 standard and didn't because there are
  3793. too many combinations of diacriticals and vowels for each combination
  3794. to have its own 8-bit representation.  The folks behind UNISTD and
  3795. the ISO 32-bit character set proposal are working with Vietnamese in
  3796. mind, so we might eventually have a standard, but for now we don't.
  3797.  
  3798. Also, I think the example was erroneous.  I think that the example
  3799. was trying to say:  "chao` ca'c  o^ng" (where the diacriticals belong
  3800. above the vowels not after them and there is no real space in the place
  3801. where the diacritical appears above).  Also, I think that the above
  3802. means "Hello everyone" more nearly than "Hello World" (though its early
  3803. in the day and I might well not have the nearest translation either :-) 
  3804.  
  3805. As I say, It was really nice to see Vietnamese as the example, but I think
  3806. that for this newsgroup it would be more accessible to use a different
  3807. language next time...
  3808.  
  3809.   Ran
  3810.   randall@Virginia.EDU
  3811.  
  3812. P.S.
  3813.   Persons interested in Vietnamese discussions should move their postings to
  3814. soc.culture.vietnamese from comp.std.unix .
  3815.  
  3816.  
  3817.  
  3818.  
  3819.  
  3820. Volume-Number: Volume 21, Number 202
  3821.  
  3822. shar.overview.a.24121
  3823. echo tag.a
  3824. cat >tag.a <<'shar.tag.a.24121'
  3825. From std-unix-request@uunet.uu.net  Mon Oct  1 14:31:10 1990
  3826. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3827.     id AA02148; Mon, 1 Oct 90 14:31:10 -0400
  3828. Posted-Date: 1 Oct 90 05:50:43 GMT
  3829. Received: by cs.utexas.edu (5.64/1.76) 
  3830. From: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)
  3831. Newsgroups: comp.std.unix,comp.lang.prolog
  3832. Subject: Re: Standards Update, U.S. TAG to ISO/IEC/JTC1/SC22 WG15
  3833. Message-Id: <564@usenix.ORG>
  3834. References: <559@usenix.ORG>
  3835. Sender: jsq@usenix.ORG
  3836. Followup-To: comp.lang.prolog
  3837. Organization: Comp Sci, RMIT, Melbourne, Australia
  3838. X-Submissions: std-unix@uunet.uu.net
  3839. Date: 1 Oct 90 05:50:43 GMT
  3840. Reply-To: std-unix@uunet.uu.net
  3841. To: std-unix@uunet.uu.net
  3842.  
  3843. Submitted-by: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)
  3844.  
  3845. In article <559@usenix.ORG> in comp.std.unix,
  3846. jsh@usenix.org (Jeffrey S. Haemer) wrote:
  3847.  
  3848. > We cannot delay language independence for 1003.1 any longer.  It's now
  3849. > really holding up international progress on important POSIX efforts.
  3850. > But what format or technique should we use?  ISO rules seem to require
  3851.                                                *************************
  3852. > an ISO-standard method, which could restrict us to VDM (Vienna
  3853. ****************************************************************
  3854. > Definition Method), but no one thinks VDM will work.  Paul Rabin and
  3855. ********************
  3856. > Steve Walli have been working on a method, but the TAG worries that a
  3857. > non-standard method will create problems like those we've suffered
  3858. > through with document formats (see last TAG report).  In order to
  3859. > avoid rejection later we will circulate the new method in SC22 and
  3860. > WG15 for review and comment.  To make this circulation useful, Donn
  3861. > Terry is listing specific questions for SC22 and WG15 to answer.
  3862. > [Editor: I believe that ISO rules only restrict us to VDM if we
  3863. > produce a formal definition, i.e., something from which one could do
  3864. > correctness proofs.  Of course, rules and politics are not always the
  3865. > same thing and using VDM might help grease the skids.  Still, we
  3866. > should stop and ask if not using VDM would hold us up any more than
  3867. > using VDM.]
  3868.  
  3869. My main interest here is in the ISO Prolog standard.  I am confused by
  3870. this extract from comp.std.unix, because the ISO Prolog standard
  3871. contains a formal specification of Prolog.  Personally, I would find it
  3872. easier to read if it _were_ in VDM.  Instead it's in a variant of
  3873. first-order logic (exact semantics unknown) with a new syntax.  This
  3874. definition was developed with the explicit intention of permitting
  3875. correctness proofs.  Does this mean that ISO _will_ accept "make up your
  3876. own formal specification language", or does it mean that the Prolog
  3877. specification in the ISO Prolog draft is forbidden by ISO rules?
  3878.  
  3879. Can someone who really knows clear this up?
  3880.  
  3881. -- 
  3882. Fixed in the next release.
  3883.  
  3884. Volume-Number: Volume 21, Number 156
  3885.  
  3886. shar.tag.a.24121
  3887. exit
  3888.