home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0137.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  2.0 KB  |  42 lines
  1. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  2.  
  3. In article <529@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
  4. > According to fouts@bozeman.bozeman.ingr (Martin Fouts):
  5. > >However, the presences of the proc file system is not a strong arguement
  6. > >for the inclusion of othere features in the file system.
  7. > I disagree.  I consider it an excellent example of how the designers
  8. > of Unix realize that all named objects potentially visible to more
  9. > than one process belong in the filesystem namespace.
  10.  
  11. I disagree. I consider it an excellent example of how the designers of
  12. UNIX realize that all *reliable*, *static*, *local* (or virtually local)
  13. I/O objects potentially visible to more than one process belong in the
  14. filesystem namespace.
  15.  
  16. /dev/proc, for example, is reliable---there's no chance of arbitrary
  17. failure. It's static---processes have inertia, and stick around until
  18. they take the positive action of exit()ing. And it's local---you don't
  19. have an arbitrary delay before seeing the information. So it's a
  20. perfectly fine thing to include in the filesystem without hesitation.
  21.  
  22. Objects that aren't reliable, or aren't static, or aren't local, also
  23. aren't necessarily sensible targets of an open(). Some of them might fit
  24. well, but each has to be considered on its own merits.
  25.  
  26. > So, how do we program in such a system?  We use its elegant interface
  27. > -- or should I say "interfaces"?  Plain files, devices, IPCs, and
  28. > network connections each have a semantically accurate interface, which
  29. > unfortunately makes it different from all others.
  30.  
  31. The single UNIX interface is the file descriptor. You can read() or
  32. write() reasonable I/O objects through file descriptors. Very few
  33. programs---the shell is a counterexample---need to worry about what it
  34. takes to set up those file descriptors. Very few programs---stty is a
  35. counterexample---need to know the ioctl()s or other functions that
  36. control the I/O more precisely. What is your complaint?
  37.  
  38. ---Dan
  39.  
  40. Volume-Number: Volume 21, Number 136
  41.  
  42.