home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0136.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  2.3 KB  |  54 lines
  1. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  2.  
  3. In article <545@usenix.ORG> ske@pkmab.se (Kristoffer Eriksson) writes:
  4. > In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  5.     [ file descriptors are general; the filesystem is not ]
  6. > What prevents us from inventing a few additional filesystem operations
  7. > that ARE general enough?
  8.  
  9. That's a good question. I am willing to believe that a somewhat
  10. different kind of filesystem could sensibly handle I/O objects that are
  11. neither reliable nor local. I find it somewhat harder to believe that
  12. the concept of a filesystem can reasonably reflect dynamic I/O:
  13. information placed into a filesystem should stick around until another
  14. explicit action.
  15.  
  16. In any case, you'll have to invent those operations first.
  17.  
  18. > I think the important thing about the filesystem abstraction that is being
  19. > debated here, is the idea of a common name space,
  20.  
  21. Here's what I thought upon reading this.
  22.  
  23. First: ``A common name space is irrelevant to the most important
  24. properties of a filesystem.''
  25.  
  26. Second: ``A common name space is impossible.''
  27.  
  28. And finally: ``We already have a common name space.''
  29.  
  30. Let me explain. My first thought was that the basic purpose of a
  31. filesystem---to provide reliable, static, local I/O---didn't require a
  32. common name space. As long as there's *some* way to achieve that goal,
  33. you have a filesystem. UNIX has not only some way, but a uniform,
  34. consistent, powerful way: file descriptors.
  35.  
  36. But that's dodging your question. Just because a common name space is
  37. irrelevant to I/O doesn't mean that it may not be helpful for some other
  38. reason. My second thought was that the kind of name space you want is
  39. impossible. You want to include network objects, but no system can
  40. possibly keep track of the tens of thousands of ports under dozens of
  41. protocols on hundreds of thousands of computer. It's just too big.
  42.  
  43. But that's not what you're looking for. Although the name space is huge,
  44. any one computer only looks at a tiny corner of that space. You only
  45. need to see ``current'' names. My third thought: We already have that
  46. common name space! (file,/bin/sh) is in that space. (host,128.122.142.2)
  47. is in that space. (proc,1) is in that space. No system call uses this
  48. common name space, but it's there. Use it at will.
  49.  
  50. ---Dan
  51.  
  52. Volume-Number: Volume 21, Number 137
  53.  
  54.