home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0058.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  3.0 KB  |  67 lines
  1. Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein)
  2.  
  3. Sean Fagan writes:
  4. > You bring up the concept of pipes, which didn't exist as files in the
  5. > original systems.  Well, a lot of things weren't in the original systems
  6. > originally, either, and lots of people seem to think that some of the
  7. > additions since V7 were a good idea.
  8.  
  9. But pipes *still* aren't in the filesystem in any popular UNIX variant.
  10. The proponents of super-open() seem to want to be able to create new
  11. files, new TCP connections, and so on with a single system call. *How is
  12. open() going to create new pipes*? If you can't answer this question
  13. then you don't really support the ``everything should be in the
  14. filesystem'' philosophy. (I certainly can't answer it.) If POSIX invents
  15. an answer then what's the chance it'll find the best technical solution?
  16.  
  17. > But a named TCP/IP socket,
  18. > to a specified host, would be nice.  (E.g., cp
  19. > /tcp/ip/ftp/uunet.uu.net/ftp/ls-lR.Z .)
  20.  
  21. So put it into your shell! There's nothing stopping you. tcsh sources
  22. are freely available.
  23.  
  24. > Can you come up with a good reason (excluding efficiency, which
  25. > I'll mention in a bit) *not* to support the creation a named pipe in the
  26. > filesystem, forking, and then unlinking it, but keeping it open?
  27.  
  28. How about this: Pipes don't belong in the filesystem. Some UNIX variants
  29. swap pipes out to disk, but most don't. What if you don't have a
  30. directory available for the mknod()? Implementing pipe() on top of
  31. mknod() is dangerous! Anyway, I don't think named pipes are really
  32. relevant to the discussion; you don't create a *new* pipe through the
  33. filesystem when you open() a named pipe.
  34.  
  35. > The question is:  is this amount of generalization worth it?  I'm not sure.
  36.  
  37. The question is: Has this amount of generalization appeared in any
  38. popular UNIX system, let alone a sufficient number of systems that we
  39. can honestly call it an industry standard?
  40.  
  41. > Tell me, Dan, how do you feel about the /dev/fd filesystem/pseeudo devices?
  42.  
  43. I think they're well-done kludges to deal with non-UNIXy programs: i.e.,
  44. programs which think that everything's a file. /dev/fd brings those
  45. programs in line with the real philosophy: everything's a file
  46. *descriptor*.
  47.  
  48. Imagine a shell syntax analogous to <$(program) which produces just a
  49. descriptor number---3 instead of /dev/fd/3. This is trivial to
  50. implement. Then imagine that the non-UNIXy programs are rewritten to
  51. take file descriptor arguments instead of filename arguments. This, too,
  52. is trivial to implement. Result: You get all the advantages of ksh's use
  53. of /dev/fd, *but you don't need a single kernel change to implement it*.
  54.  
  55. Perhaps you're right. Perhaps super-open() would make life simpler for
  56. UNIX programmers. But I don't see anything it can do which file
  57. descriptors can't do in combination with well-written utilities. I am
  58. disgusted at the idea that POSIX members ``expect'' super-open() to be
  59. ``standardized.'' Where's the history of failures and successes in
  60. solving the problem (if there even is a problem!) of opening files?
  61.  
  62. ---Dan
  63.  
  64.  
  65. Volume-Number: Volume 26, Number 69
  66.  
  67.