home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0069.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  3.9 KB  |  77 lines
  1. Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein)
  2.  
  3. Let me quickly mention an alternative to super-open(): namely, pdopen(),
  4. which is called as (e.g.) pdopen("openin","foo",O_RDONLY) and returns a
  5. file descriptor for reading from foo. Internally pdopen() executes
  6. execlp("openin","openin","foo","pdopenr",(char *) 0). openin opens foo
  7. for reading as fd 0 and then runs pdopenr, which gives a descriptor back
  8. to the original process through fd passing. One feature of pdopen() is
  9. that users can customize it easily: right now I can call
  10.  
  11.   pdopen("ftpread","wuarchive.wustl.edu:usenet/alt.sources/articles/4655",0)
  12.  
  13. and get a descriptor which reads from that file on wuarchive. Utilities
  14. can use the syntax <&openin:foo. Voila: Uniform access to network files
  15. and local files. No system changes required---the code for everything I
  16. mentioned above already works on BSD, and I suppose that if I spend a
  17. little more time on it, I could have pdopenr shuttle data through pipes
  18. so that it doesn't need fd passing.
  19.  
  20. Why am I bringing up this invention on comp.std.unix? Because I'm trying
  21. to make clear that it's just an *invention*, just like a version of
  22. open() with the same features would be. There are many possible
  23. solutions to the problem of accessing network files. super-open() would
  24. have the advantage of working with programs which used open(). pdopen()
  25. has the advantage of letting the user customize it easily. Neither is
  26. appropriate for standardization, because no industry consensus exists.
  27.  
  28. Peter writes:
  29. > I think Dan has a couple of basic problems in his argument here: first,
  30. > looking at extensions to the file system as extensions to "open"; and
  31. > second, missing the huge amount of code that comprises the "normal" UNIX
  32. > environment that depends on a uniform name space.
  33.  
  34. I would like to correct three parts of Peter's summaries of my position.
  35. First of all, Peter keeps bringing up syscalls other than open() which
  36. manipulate filenames and which cannot be written in terms of file
  37. descriptors. For example, creat(), link(), chmod(), and unlink() are
  38. nonsensical without the concept of a filesystem. Peter then claims that
  39. if there are mechanisms other than open() for creating file descriptors,
  40. then the functions of creat(), link(), chmod(), and unlink() must all be
  41. duplicated for those other mechanisms. But this is clearly nonsense: v7
  42. had pipes, and didn't implement chmod() for pipes, and nobody has yet
  43. complained at this omission. BSD had TCP/IP sockets, and didn't
  44. implement chmod() for sockets, and nobody's complained about that
  45. either. The protection mechanisms for the filesystem make sense for the
  46. filesystem and *not* for network connections. So there is *no* need for
  47. a version of chmod() (or any other filesystem-specific syscall) which
  48. applies to network connections. BSD has a different, and much more
  49. appropriate, protection mechanism for sockets; I'm glad that CSRG took
  50. the time to work out good semantics for bind() rather than blindly
  51. applying chmod() to some bastard network-filesystem creation.
  52.  
  53. Second, Peter says that I'm arguing against any form of uniform
  54. namespace. Not at all. What I'm arguing against is the ``expectation''
  55. of many POSIX members that POSIX will ``standardize'' an open() which
  56. does something which has not won the market. If open() had worked for
  57. network connections from the beginning, I wouldn't be complaining about
  58. this issue in comp.std.unix.
  59.  
  60. Finally, Peter states
  61.  
  62. > Another problem with Dan's suggestions is that they reduce the name space
  63. > available for normal files: a name space that's already hurt by the UNIX
  64. > option syntax. If you start defining "3" to mean file descriptor 3,
  65.  
  66. but what I meant by this was that file descriptor numbers be used
  67. *instead* of filenames, with the shell responsible for making this
  68. transparent to the user. A utility which has already been mis-designed
  69. to use filenames can stick to /dev/fd/3, which as I said before is a
  70. rather good kludge to make such utilities behave.
  71.  
  72. ---Dan
  73.  
  74.  
  75. Volume-Number: Volume 26, Number 79
  76.  
  77.