home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0196.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  4.3 KB  |  91 lines
  1. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  2.  
  3. I was not planning to post further on this topic, but Chip has provided
  4. some good arguments that deserve a proper rebuttal.
  5.  
  6. In article <13392@cs.utexas.edu> chip@tct.uucp (Chip Salzenberg) writes:
  7. > It is true that interactive use of UNIX, especially by programmers,
  8. > puts a lot of emphasis on the shell interface.  If such an environment
  9. > were all there were to Unix, then Dan's fd-centric view of the world
  10. > could possibly be useful.
  11.  
  12. The success of UNIX has proven how useful this ``fd-centric'' view is.
  13.  
  14. > To use Richard's example: when a hyperspace
  15. > shunt became available, its use would require only a change to the
  16. > shell source code and a recompilation.
  17.  
  18. You are making an unwarranted assumption here: that the shell *has* to
  19. handle all types of fd creation. It's convenient, of course, but by no
  20. means necessary. My TCP connectors, for example, are implemented outside
  21. the shell.
  22.  
  23. > However, the reality of modern Unix use is something else entirely:
  24. > pre-packaged utilities, usually available only as binaries, that for
  25. > practical purposes *cannot* be changed or replaced.  In this
  26. > environment, kernel features that require program customization are
  27. > unwieldy at best, useless at worst.  As long as shells fall into this
  28. > category -- "programs usually distributed as binaries" -- fd-centric
  29. > UNIX will never be practical.
  30.  
  31. This is also unfounded. My TCP connectors provide a counterexample to
  32. your hypothesis (that the shell must handle everything and hence be
  33. recompiled) and your conclusion (that fd-centric UNIX doesn't work).
  34. Any programming problem can be solved by adding a level of indirection.
  35.  
  36. > One could argue that binary-only distribution is evil and should be
  37. > stopped.
  38.  
  39. I do, in fact, think exactly that. But I will not use it as a basis for
  40. my arguments.
  41.  
  42. > Finally, filenames often are stored in places where no shell will ever
  43. > see them, such as program-specific configuration files.  So in Dan's
  44. > hypothetical fd-centric UNIX, we would have to either (1) pass such
  45. > filenames to the shell for interpretation, thus incurring a possibly
  46. > substantial performance hit; or (2) modify each program to understand
  47. > all the names the shell would understand.  In my opinion, neither of
  48. > these alternatives is viable.
  49.  
  50. On the contrary. syslog is a counterexample. While it is hardly as
  51. modular as I would like, it shows that (0) an fd-centric model works;
  52. (1) you do not need to invoke the shell or any other process, and you do
  53. not need to incur a performance hit; (2) you do not need to modify each
  54. program to understand everything that the syslogd program can. syslog
  55. has proven quite viable.
  56.  
  57. Provided that there is a message-passing facility available, and
  58. provided that it has sufficient power to pass file descriptors (which is
  59. true both under BSD's UNIX-domain sockets and under System V's streams),
  60. the syslog model will generalize to any I/O mechanism without loss of
  61. efficiency. open() can always be replaced by a write() to the facility
  62. followed by a file descriptor transfer. This is just as easy to do
  63. outside the kernel as inside the kernel; therefore it should be outside.
  64.  
  65. > To summarize:
  66. > A unified namespace has one great advantage: new types of objects are
  67. > immediately available to all programs -- even the programs for which
  68. > you do not have the means or the desire to modify and recompile.
  69.  
  70. To summarize: I believe I've provided counterexamples to each of your
  71. arguments and conclusions, and so I continue to maintain that a unified
  72. namespace is pointless. There is no need to recompile any programs just
  73. to provide a new I/O mechanism.
  74.  
  75. A unified namespace has several great disadvantages: 1. It provides a
  76. competing abstraction with file descriptors, hence adding complexity to
  77. the kernel, and giving vendors two different outlets for extensions.
  78. This will result in a confused system, where some features are available
  79. only under one abstraction or the other. 2. It is not clear that all
  80. sensible I/O objects will fit into one namespace. If the precedent of a
  81. unified namespace is established now, I/O objects that don't fit will be
  82. much harder to add later. 3. A unified namespace has not been tested on
  83. a large scale in the real world, and hence is an inappropriate object of
  84. standardization at this time.
  85.  
  86. ---Dan
  87.  
  88.  
  89. Volume-Number: Volume 21, Number 195
  90.  
  91.