home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0086.txt < prev    next >
Encoding:
Internet Message Format  |  1990-10-26  |  1.5 KB
  1. From:  peter da silva <peter@ficc.ferranti.com>
  2.  
  3. In article <488@usenix.ORG> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
  4. > > My personal opinion is that *anything* that can go into the file system
  5. > > name space *should*. That's what makes UNIX UNIX... that it's all visible
  6. > > from the shell...
  7.  
  8. > I'm not sure which Unix you've been running for the past five or more
  9. > years, but a lot of stuff doesn't live in the file system name space
  10. > under various BSD derived systems,
  11.  
  12. Yes, and there's even more stuff in System V that doesn't live in that
  13. name space. In both cases it's *wrong*.
  14.  
  15. > nor do the networking types believe
  16. > it belongs there.
  17.  
  18. Some more details on this subject would be advisable. I'm aware that not
  19. everything *can* go in the file system name space, by the way...
  20.  
  21. > IMHO neither does a process handle, nor a
  22. > semaphore, and don't even talk to me about "named pipes" as an IPC
  23. > mechanism.
  24.  
  25. An active semaphore can be implemented any way you want, but it should
  26. be represented by an entry in the name space. The same goes for process
  27. handles and so on.
  28.  
  29. Named pipes are an inadequate mechanism for much IPC, but they work quite
  30. well for many simple cases. If you're looking at them as some sort of
  31. paragon representing the whole concept, you're sadly mistaken.
  32.  
  33. Anyway... what is it that makes "dev/win" more worthy of having an entry
  34. in "/dev" than "dev/socket"?
  35. -- 
  36. Peter da Silva.   `-_-'
  37. +1 713 274 5180.   'U`
  38. peter@ferranti.com
  39.  
  40. Volume-Number: Volume 21, Number 87
  41.  
  42.