home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 119 < prev    next >
Internet Message Format  |  1990-12-05  |  3KB
  1. From std-unix-request@uunet.uu.net  Thu Sep 20 14:20:46 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA10926; Thu, 20 Sep 90 14:20:46 -0400
  4. Posted-Date: 20 Sep 90 12:48:04 GMT
  5. Received: by cs.utexas.edu (5.64/1.76) 
  6. From: tct!chip@cs.utexas.edu (Chip Salzenberg)
  7. Newsgroups: comp.std.unix
  8. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  9. Message-Id: <529@usenix.ORG>
  10. References: <488@usenix.ORG> <495@usenix.ORG> <523@usenix.ORG>
  11. Sender: jsq@usenix.ORG
  12. Organization: Teltronics/TCT, Sarasota, FL
  13. X-Submissions: std-unix@uunet.uu.net
  14. Date: 20 Sep 90 12:48:04 GMT
  15. Reply-To: std-unix@uunet.uu.net
  16. To: std-unix@uunet.uu.net
  17.  
  18. Submitted-by: chip@tct.uucp (Chip Salzenberg)
  19.  
  20. According to fouts@bozeman.bozeman.ingr (Martin Fouts):
  21. >According to chip@tct.uucp (Chip Salzenberg):
  22. >> Research Unix [...] put *more things [in the filesystem],
  23. >> including processes (via the /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.
  27.  
  28. With /proc, some things are much easier.  (Getting a list of all
  29. active pids, for example.)  Nothing, however, is harder.  A big win.
  30.  
  31. >However, the presences of the proc file system is not a strong arguement
  32. >for the inclusion of othere features in the file system.
  33.  
  34. I disagree.  I consider it an excellent example of how the designers
  35. of Unix realize that all named objects potentially visible to more
  36. than one process belong in the filesystem namespace.
  37.  
  38. >Unix programming has a history of using the filesystem for some things
  39. >and not using it for others.  For example, I can demonstrate a
  40. >semantic under which it is possible to put the time of day clock into
  41. >the file system ...
  42.  
  43. Of course.  But in the absense of remotely mounted filesystems --
  44. which V7 Unix was not designed to support -- there is only one time of
  45. day, so it needs no name.  (I wouldn't be surprised if Plan 9 has a
  46. /dev/timeofday, however.)
  47.  
  48. >... not all functions which might have been placed in the
  49. >filesystem automatically have.
  50.  
  51. This observation is correct.  But it is clear that the designers of
  52. Research Unix have used the filesystem for everything that needs a
  53. name, and they continue to do so.  Their work asks, "Why have multiple
  54. namespaces?"  Plan 9 asks the question again, and with a megaphone.
  55.  
  56. >Because of the way network connections are made, I have been
  57. >convinced by networking experts (who are familiar with the "Unix
  58. >style") that the filesystem namespace does not have a good semantic
  59. >match for the network name space.
  60.  
  61. Carried to its logical conclusion, this argument would invalidate
  62. special files and named pipes, since they also lack a "good semantic
  63. match" with flat files.  In fact, the only entities with a "good
  64. semantic match" for flat files are -- you guessed it -- flat files.
  65.  
  66. So, how do we program in such a system?  We use its elegant interface
  67. -- or should I say "interfaces"?  Plain files, devices, IPCs, and
  68. network connections each have a semantically accurate interface, which
  69. unfortunately makes it different from all others.
  70.  
  71. This is progress?  "Forward into the past!"
  72. -- 
  73. Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
  74.  
  75. Volume-Number: Volume 21, Number 119
  76.  
  77.