home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0113.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  3.9 KB  |  86 lines
  1. Submitted-by: fouts@bozeman.bozeman.ingr (Martin Fouts)
  2.  
  3. >>>>> On 7 Sep 90 15:23:19 GMT, chip@tct.uucp (Chip Salzenberg) said:
  4.  
  5. Chip> According to fouts@bozeman.bozeman.ingr (Martin Fouts):
  6. >I'm not sure which Unix you've been running for the past five or more
  7. >years, but a lot of stuff doesn't live in the file system name space ...
  8.  
  9. Chip> The absense of sockets (except UNIX domain), System V IPC, etc. from
  10. Chip> the file system is, in the opinion of many, a bug.  It is a result of
  11. Chip> Unix being extended by people who do not understand Unix.
  12.                              ^-------------------------------^
  13.  
  14. My aren't we superior.  (;-) At one time, I believed that sockets
  15. belonged in the filesystem name space.  I spent a long time arguing
  16. this point with members of the networking community before they
  17. convinced me that certain transient objects do not belong in that name
  18. space.  (See below)
  19.  
  20. Chip> Research Unix, which is the result of continued development by the
  21. Chip> creators of Unix, did not take things out of the filesystem.  To the
  22. Chip> contrary, it put *more* things there, including processes (via the
  23. Chip> /proc pseudo-directory).
  24.  
  25. The value of proc in the file system are debatable.  Certain debugging
  26. tools are easier to hang on an fcntl certain others are not.  However, the
  27. presences of the proc file system is not a strong arguement for the
  28. inclusion of othere features in the file system.
  29.  
  30. Chip> It is true that other operating systems get along without devices,
  31. Chip> IPC, etc. in their filesystems.  That's fine for them; but it's not
  32. Chip> relevant to Unix.  Unix programming has a history of relying on the
  33. Chip> filesystem to take care of things that other systems handle as special
  34. Chip> cases -- devices, for example.  The idea that devices can be files but
  35. Chip> TCP/IP sockets cannot runs counter to all Unix experience.
  36.  
  37. Unix programming has a history of using the filesystem for some things
  38. and not using it for others.  For example, I can demonstrate a
  39. semantic under which it is possible to put the time of day clock into
  40. the file system and reference it by opening the i.e. /dev/timeofday
  41. file.  Each time I read from that file, I would get the current time.
  42. Via fcntls, I could extend this to handle timer functions.  It wasn't
  43. done in Unix.  (I've done similar things in other OSs I've designed,
  44. though.)
  45.  
  46. The whole point of the response which you partially quoted was to
  47. remind the poster I was responding to that not all functions which
  48. might have been placed in the filesystem automatically have.
  49.  
  50. Chip> The reason why I continue this discussion here, in comp.std.unix, is
  51. Chip> that many Unix programmers hope that the people in the standardization
  52. Chip> committees have learned from the out-of-filesystem mistake, and will
  53. Chip> rectify it.
  54. Chip> --
  55.  
  56. The reason I respond is that it is not automatically safe to assume
  57. that something belongs in the file system because something else is
  58. already there.  There is also an explicit problem not mentioned in
  59. this discussion which is the distinction between filesystem name space
  60. and filesystem semantics.  Sometimes there are objects which would be
  61. reasonable to treat with filesystem semantics for which there is no
  62. reasonable mechanism for introducing them into the filesystem name
  63. space.  Because of the way network connections are made, I have been
  64. convinced by networking experts (who are familiar with the "Unix
  65. style") that the filesystem namespace does not have a good semantic
  66. match for the network name space.
  67.  
  68. Chip> Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  69.  
  70. Chip> Volume-Number: Volume 21, Number 89
  71.  
  72. Marty
  73. --
  74. Martin Fouts
  75.  
  76.  UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
  77.  ARPA:  apd!fouts@ingr.com
  78. PHONE:  (415) 852-2310            FAX:  (415) 856-9224
  79.  MAIL:  2400 Geng Road, Palo Alto, CA, 94303
  80.  
  81. Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  82.   -  Frank Zappa
  83.  
  84. Volume-Number: Volume 21, Number 114
  85.  
  86.