home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0204.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  4.5 KB  |  107 lines
  1. Submitted-by: chip@tct.uucp (Chip Salzenberg)
  2.  
  3.  
  4. According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
  5. >You are making an unwarranted assumption here: that the shell *has* to
  6. >handle all types of fd creation. It's convenient, of course, but by no
  7. >My TCP connectors, for example, are implemented outside the shell.
  8.  
  9. Yes, the shell can be let off the hook.  The point I was making,
  10. however, is still valid.  Without a unified namespace, new types of
  11. objects require *some* program to be written and/or modified.  And
  12. such programming isn't always available where it would be needed.
  13.  
  14. >> In Dan's hypothetical fd-centric UNIX, we would have to either
  15. >> (1) pass such filenames to the shell for interpretation, thus incurring
  16. >> a possibly substantial performance hit; or (2) modify each program to
  17. >> understand all the names the shell would understand.
  18. >
  19. >On the contrary. syslog is a counterexample.
  20.  
  21. If syslog is your best example of a zero-programming fd-centric
  22. service, then your position is mighty weak.  A program that uses a
  23. syslog-style service must make a call to one or more service-specific
  24. subroutines.  Thus, if a new server is brought on line, program
  25. modification will be required before the new server can be used.
  26.  
  27. And, of course, there is the vast number of programs that already
  28. exist and use open() exclusively.  Perhaps academics can blow off an
  29. installed base, but we commercial money-grubbers can't afford the
  30. luxury of modifying everything we've ever written -- even just once.
  31.  
  32. >... [syslog] shows that an fd-centric model works ...
  33.  
  34. Actually, it shows that fd's *with* a unified namespace are useful.
  35. How, pray tell, do you think openlog() gets its fd?  Via the *name*
  36. "/dev/log".  Syslog depends on the unified namespace (such as it is).
  37.  
  38. >(1) you do not need to invoke the shell or any other process, and you do
  39. >not need to incur a performance hit;
  40.  
  41. Granted.
  42.  
  43. >(2) you do not need to modify each program to understand everything
  44. >that the syslogd program can.  Syslog has proven quite viable.
  45.  
  46. True ... once the program uses syslog() or an equivalent service.
  47. But the binaries out there in the world don't.
  48.  
  49. >Provided that there is a message-passing facility available, and
  50. >provided that it has sufficient power to pass file descriptors (which is
  51. >true both under BSD's UNIX-domain sockets and under System V's streams),
  52. >the syslog model will generalize to any I/O mechanism without loss of
  53. >efficiency.
  54.  
  55. Aha!  So the New, Improved and Expanded syslog becomes the system-wide
  56. name-to-fd translator.  Furthermore, since new servers would require
  57. changes to all clients, the system-wide name-to-fd translator knows
  58. about all available object types.  I think I see the light.
  59.  
  60. But the server needs a name, if for no other reason than to provide a
  61. library binding.  My suggestion is -- can you guess? -- "open()".
  62.  
  63. It's deja vu all over again.
  64.  
  65. >This is just as easy to do outside the kernel as inside the kernel;
  66. >therefore it should be outside.
  67.  
  68. The server's location is irrelevant.  Its existence is not.
  69.  
  70. >A unified namespace has several great disadvantages: 1. It provides a
  71. >competing abstraction with file descriptors ...
  72.  
  73. As Peter da Silva said: Think synergy.  Names are desciptions of
  74. passive objects; fds are descriptions of active (open) objects.
  75. There's no competitition involved.
  76.  
  77. My idea of harmful competition is multiple abstractions for passive
  78. objects -- pathnames, struct sockaddrs and SysV IPC keys -- and for
  79. active objects -- fds, SysV IPC ids -- each of which has its own set
  80. of open/read/write/close analogues.  I therefore consider both SysV
  81. IPC and BSD sockets to be botches due to their competition with the
  82. Unix name/fd abstraction.  (I'd have a better opinion of sockets if
  83. the socket() call didn't exist and if connect() were named open().)
  84.  
  85. >2. It is not clear that all sensible I/O objects will fit into one
  86. >namespace.
  87.  
  88. It's clear to me.
  89.  
  90. >3. A unified namespace has not been tested on a large scale in the
  91. >real world, and hence is an inappropriate object of standardization
  92. >at this time.
  93.  
  94. "Advancement by invented standards" is an oxymoron, true.  Given that
  95. POSIX seems to be intent on inventing *something*, though, I push for
  96. a unified namespace.  Several people have described work with Unix (or
  97. Unix-like) systems that keep everything in one namespace.  And surely
  98. Plan 9 counts as "prior art."
  99. -- 
  100. Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  101.     "I've been cranky ever since my comp.unix.wizards was removed
  102.          by that evil Chip Salzenberg."   -- John F. Haugh II
  103.  
  104.  
  105. Volume-Number: Volume 21, Number 203
  106.  
  107.