home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 137 < prev    next >
Internet Message Format  |  1990-12-05  |  3KB
  1. From std-unix-request@uunet.uu.net  Thu Sep 27 13:32:28 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA03619; Thu, 27 Sep 90 13:32:28 -0400
  4. Posted-Date: 27 Sep 90 02:06:52 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: <549@usenix.ORG>
  10. References: <539@usenix.ORG> <541@usenix.ORG> <545@usenix.ORG>
  11. Sender: jsq@usenix.ORG
  12. Organization: IR
  13. X-Submissions: std-unix@uunet.uu.net
  14. Date: 27 Sep 90 02:06:52 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 <545@usenix.ORG> ske@pkmab.se (Kristoffer Eriksson) writes:
  21. > In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  22.     [ file descriptors are general; the filesystem is not ]
  23. > What prevents us from inventing a few additional filesystem operations
  24. > that ARE general enough?
  25.  
  26. That's a good question. I am willing to believe that a somewhat
  27. different kind of filesystem could sensibly handle I/O objects that are
  28. neither reliable nor local. I find it somewhat harder to believe that
  29. the concept of a filesystem can reasonably reflect dynamic I/O:
  30. information placed into a filesystem should stick around until another
  31. explicit action.
  32.  
  33. In any case, you'll have to invent those operations first.
  34.  
  35. > I think the important thing about the filesystem abstraction that is being
  36. > debated here, is the idea of a common name space,
  37.  
  38. Here's what I thought upon reading this.
  39.  
  40. First: ``A common name space is irrelevant to the most important
  41. properties of a filesystem.''
  42.  
  43. Second: ``A common name space is impossible.''
  44.  
  45. And finally: ``We already have a common name space.''
  46.  
  47. Let me explain. My first thought was that the basic purpose of a
  48. filesystem---to provide reliable, static, local I/O---didn't require a
  49. common name space. As long as there's *some* way to achieve that goal,
  50. you have a filesystem. UNIX has not only some way, but a uniform,
  51. consistent, powerful way: file descriptors.
  52.  
  53. But that's dodging your question. Just because a common name space is
  54. irrelevant to I/O doesn't mean that it may not be helpful for some other
  55. reason. My second thought was that the kind of name space you want is
  56. impossible. You want to include network objects, but no system can
  57. possibly keep track of the tens of thousands of ports under dozens of
  58. protocols on hundreds of thousands of computer. It's just too big.
  59.  
  60. But that's not what you're looking for. Although the name space is huge,
  61. any one computer only looks at a tiny corner of that space. You only
  62. need to see ``current'' names. My third thought: We already have that
  63. common name space! (file,/bin/sh) is in that space. (host,128.122.142.2)
  64. is in that space. (proc,1) is in that space. No system call uses this
  65. common name space, but it's there. Use it at will.
  66.  
  67. ---Dan
  68.  
  69. Volume-Number: Volume 21, Number 137
  70.  
  71.