home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 075 < prev    next >
Internet Message Format  |  1990-12-05  |  3KB
  1. From std-unix-request@uunet.uu.net  Thu Aug 30 14:19:34 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA03268; Thu, 30 Aug 90 14:19:34 -0400
  4. Posted-Date: 30 Aug 90 15:07:04 GMT
  5. Received: by cs.utexas.edu (5.64/1.76) 
  6. From: preece@urbana.mcd.mot.com (Scott E. Preece)
  7. Newsgroups: comp.std.unix
  8. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  9. Message-Id: <478@usenix.ORG>
  10. References: <448@usenix.ORG> <467@usenix.ORG> <470@usenix.ORG>
  11. Sender: std-unix@usenix.ORG
  12. Organization: Motorola MCD, Urbana Design Center
  13. X-Submissions: std-unix@uunet.uu.net
  14. Date: 30 Aug 90 15:07:04 GMT
  15. Reply-To: std-unix@uunet.uu.net
  16. To: std-unix@uunet.uu.net
  17.  
  18. From:  preece@urbana.mcd.mot.com (Scott E. Preece)
  19.  
  20. | From:  sp@mysteron.osf.org (Simon Patience)
  21.  
  22. | The reason for semaphores not being in the file system is twofold. Some
  23. | realtime embedded systems do not have a file system but do want semaphores
  24. | So this allows them to have them without having to bring in the baggage a
  25. | file system would entail.
  26. ---
  27. I don't care whether they have something that looks like UNIX filesystem
  28. code or not, or whether they have disk drives or not, but I don't think
  29. it's unreasonable to require them to handle semaphore names as though
  30. they were in a filesystem namespace.  Otherwise you're going to end up
  31. with a collection of independent features, each minimally specified so
  32. that it can work without assuming anything else, and anyone with any
  33. sense is going to say "Yuck" and use a real operating system that
  34. provides reasonable integration and for a uniform notion of, among other
  35. things, naming.
  36. ---
  37. | ...         Secondly, as far as threads, which are supposed to
  38. | be light weight, are concerned it allows semaphores to be implmented in user
  39. | space rather than forcing them into the kernel for the file system.
  40. ---
  41. Eh?  I don't know what the group has proposed since the ballot, but it
  42. would seem that using a filesystem name only makes a difference when you
  43. first specify you're going to be looking at a particular semaphore,
  44. which shouldn't be a critical path event.  After that you use a file
  45. descriptor, which I think could be handled in user space about as well
  46. as anything else.  In either case you're going to have to go to the
  47. kernel when scheduling is required (when you block or when you release
  48. the semaphore).
  49. ---
  50. | A good reason for *not* having IPC handles in the file system is to allow
  51. | network IPC to use the same interfaces. If you have IPC handles in the
  52. | file system then two machines who have applications trying to communicate
  53. | would also have to have at least part of their file system name space to
  54. | be shared. This is non trivial to arrange for two machines so can you
  55. | imaging the problem of doing this for 100 (or 1000?) machines.
  56. ---
  57. You're going to have to synchronize *some* namespace anyway, why
  58. shouldn't it be a piece of the filesystem namespace?
  59.  
  60. A consistent approach to naming and name resolution for ALL global
  61. objects should be one of the basic requirements for any new POSIX (or
  62. UNIX!) functionality.  We should have *one* namespace so that we can
  63. write general tools that only need to know about one namespace.
  64. --
  65. scott preece
  66. motorola/mcd urbana design center    1101 e. university, urbana, il   61801
  67. uucp:    uunet!uiucuxc!udc!preece,     arpa:    preece@urbana.mcd.mot.com
  68.  
  69. Volume-Number: Volume 21, Number 75
  70.  
  71.