home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0118.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  2.6 KB  |  60 lines
  1. Submitted-by: chip@tct.uucp (Chip Salzenberg)
  2.  
  3. According to fouts@bozeman.bozeman.ingr (Martin Fouts):
  4. >According to chip@tct.uucp (Chip Salzenberg):
  5. >> Research Unix [...] put *more things [in the filesystem],
  6. >> including processes (via the /proc pseudo-directory).
  7. >
  8. >The value of proc in the file system are debatable.  Certain debugging
  9. >tools are easier to hang on an fcntl certain others are not.
  10.  
  11. With /proc, some things are much easier.  (Getting a list of all
  12. active pids, for example.)  Nothing, however, is harder.  A big win.
  13.  
  14. >However, the presences of the proc file system is not a strong arguement
  15. >for the inclusion of othere features in the file system.
  16.  
  17. I disagree.  I consider it an excellent example of how the designers
  18. of Unix realize that all named objects potentially visible to more
  19. than one process belong in the filesystem namespace.
  20.  
  21. >Unix programming has a history of using the filesystem for some things
  22. >and not using it for others.  For example, I can demonstrate a
  23. >semantic under which it is possible to put the time of day clock into
  24. >the file system ...
  25.  
  26. Of course.  But in the absense of remotely mounted filesystems --
  27. which V7 Unix was not designed to support -- there is only one time of
  28. day, so it needs no name.  (I wouldn't be surprised if Plan 9 has a
  29. /dev/timeofday, however.)
  30.  
  31. >... not all functions which might have been placed in the
  32. >filesystem automatically have.
  33.  
  34. This observation is correct.  But it is clear that the designers of
  35. Research Unix have used the filesystem for everything that needs a
  36. name, and they continue to do so.  Their work asks, "Why have multiple
  37. namespaces?"  Plan 9 asks the question again, and with a megaphone.
  38.  
  39. >Because of the way network connections are made, I have been
  40. >convinced by networking experts (who are familiar with the "Unix
  41. >style") that the filesystem namespace does not have a good semantic
  42. >match for the network name space.
  43.  
  44. Carried to its logical conclusion, this argument would invalidate
  45. special files and named pipes, since they also lack a "good semantic
  46. match" with flat files.  In fact, the only entities with a "good
  47. semantic match" for flat files are -- you guessed it -- flat files.
  48.  
  49. So, how do we program in such a system?  We use its elegant interface
  50. -- or should I say "interfaces"?  Plain files, devices, IPCs, and
  51. network connections each have a semantically accurate interface, which
  52. unfortunately makes it different from all others.
  53.  
  54. This is progress?  "Forward into the past!"
  55. -- 
  56. Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  57.  
  58. Volume-Number: Volume 21, Number 119
  59.  
  60.