home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0067.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  3.2 KB  |  67 lines
  1. Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein)
  2.  
  3. Sean's right that discussions of possible future extensions to UNIX
  4. don't belong anywhere near comp.std.unix, so I'll stick to the points
  5. relevant to standardizing a super-open(). To review the main issue: Many
  6. POSIX members seem to think that POSIX should standardize a version of
  7. open() which can open network connections. I find this position utterly
  8. ridiculous. I once again accuse POSIX of standardizing inventions which
  9. nobody has implemented, let alone tried on the market.
  10.  
  11. Sean writes:
  12. > In article <1992Jan8.231229.23299@uunet.uu.net> brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein) writes:
  13. > >But pipes *still* aren't in the filesystem in any popular UNIX variant.
  14. > You mean like xenix?  (200k installed systems, as far as I know, all of them
  15. > have named pipes.
  16.  
  17. Please read what I wrote. As I said before, open() doesn't let you
  18. *create* a pipe in any popular UNIX variant. Named pipes are *not* new
  19. pipes. To create a named pipe you need mknod() (or POSIX mkfifo()).
  20.  
  21.   [ network connections ]
  22. > >So put it into your shell! There's nothing stopping you. tcsh sources
  23. > >are freely available.
  24. > That doesn't help any other case, Dan.  Such as a program wanting to open up
  25. > a connection to some other site.  I guess you're advocating using popen()
  26. > instead of open for every case, right?
  27.  
  28. As I said before, tools like sh and editors are powerful enough to open
  29. programs as well as files. vi already calls the shell automatically if
  30. it sees any special characters; if you gave your shell a syntax for
  31. network connections, vi would automatically use that syntax. Less
  32. powerful utilities don't need to open network connections any more than
  33. they need to open files; they can stick to file descriptors.
  34.  
  35. > >The question is: Has this amount of generalization appeared in any
  36. > >popular UNIX system, let alone a sufficient number of systems that we
  37. > >can honestly call it an industry standard?
  38. > Plan 9.  Version 8.  BSD 4.4 will probably have a /proc, SysVr4 already
  39. > does.
  40.  
  41. /proc is not the same as a super-open(). I have no objection to POSIX
  42. documenting features which the industry has agreed on. The industry has
  43. not agreed on an open() which can create network connections. Period.
  44.  
  45. > There was a proposal, a year or so ago, to create a 'fdlink()' system call,
  46. > that would create a name in the filesystem for any given file descriptor.
  47.  
  48. May I remind you that I was one of the proponents of that syscall? And
  49. that it was only supposed to work for regular files which were already
  50. stored in the same filesystem, for the same reason that link() only
  51. works for names in the same filesystem?
  52.  
  53. ---Dan
  54.  
  55. [ To save everyone a lot of anguish:  Dan, most people here haven't
  56.   argued that open() should create things, such as network connections.
  57.   But we are arguing that it fits the unix model to have them in the
  58.   filesystem's namespace; if you are not against /proc, you cannot be
  59.   against /tcp or /net or whatever it decides to be called, as they are
  60.   essentially the same thing:  using the namespace to get at things
  61.   normally only accessible through twisted mazes.  Both cases put some
  62.   (or all) of the work onto the filesystem (be it in the kernel, a user-
  63.   process, or whatever). -- mod ]
  64.  
  65. Volume-Number: Volume 26, Number 78
  66.  
  67.