home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 136 < prev    next >
Internet Message Format  |  1990-12-05  |  3KB
  1. From std-unix-request@uunet.uu.net  Thu Sep 27 13:33:06 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA03783; Thu, 27 Sep 90 13:33:06 -0400
  4. Posted-Date: 24 Sep 90 21:56:28 GMT
  5. Received: by cs.utexas.edu (5.64/1.76) 
  6. From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  7. Newsgroups: comp.std.unix
  8. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  9. Message-Id: <548@usenix.ORG>
  10. References: <495@usenix.ORG> <523@usenix.ORG> <529@usenix.ORG>
  11. Sender: jsq@usenix.ORG
  12. Organization: IR
  13. X-Submissions: std-unix@uunet.uu.net
  14. Date: 24 Sep 90 21:56:28 GMT
  15. Reply-To: std-unix@uunet.uu.net
  16. To: std-unix@uunet.uu.net
  17.  
  18. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  19.  
  20. In article <529@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
  21. > According to fouts@bozeman.bozeman.ingr (Martin Fouts):
  22. > >However, the presences of the proc file system is not a strong arguement
  23. > >for the inclusion of othere features in the file system.
  24. > I disagree.  I consider it an excellent example of how the designers
  25. > of Unix realize that all named objects potentially visible to more
  26. > than one process belong in the filesystem namespace.
  27.  
  28. I disagree. I consider it an excellent example of how the designers of
  29. UNIX realize that all *reliable*, *static*, *local* (or virtually local)
  30. I/O objects potentially visible to more than one process belong in the
  31. filesystem namespace.
  32.  
  33. /dev/proc, for example, is reliable---there's no chance of arbitrary
  34. failure. It's static---processes have inertia, and stick around until
  35. they take the positive action of exit()ing. And it's local---you don't
  36. have an arbitrary delay before seeing the information. So it's a
  37. perfectly fine thing to include in the filesystem without hesitation.
  38.  
  39. Objects that aren't reliable, or aren't static, or aren't local, also
  40. aren't necessarily sensible targets of an open(). Some of them might fit
  41. well, but each has to be considered on its own merits.
  42.  
  43. > So, how do we program in such a system?  We use its elegant interface
  44. > -- or should I say "interfaces"?  Plain files, devices, IPCs, and
  45. > network connections each have a semantically accurate interface, which
  46. > unfortunately makes it different from all others.
  47.  
  48. The single UNIX interface is the file descriptor. You can read() or
  49. write() reasonable I/O objects through file descriptors. Very few
  50. programs---the shell is a counterexample---need to worry about what it
  51. takes to set up those file descriptors. Very few programs---stty is a
  52. counterexample---need to know the ioctl()s or other functions that
  53. control the I/O more precisely. What is your complaint?
  54.  
  55. ---Dan
  56.  
  57. Volume-Number: Volume 21, Number 136
  58.  
  59.