buz@@eng.ready.com (Greg Buzzard) (06/25/91)
What is the reason for the mach_port_allcate_name function being in the kernel interface? It seems to me that all it does (over and above what mach_port_allocate does) is make implementations more difficult. That is, this is the only reason that I can think of that would cause me to use a splay tree in the port name lookup facitily. Similarly, it seems that it would have been nice if mach_port_insert_right was restricted to only insert rights using a "name" that had been previously extracted. Am I missing some implicit rationale for this interface? -- Greg Buzzard internet: buz@eng.ready.com Ready Systems 470 Potrero Ave. phone: 408/736-2600 Sunnyvale, CA 94086
mib@geech.gnu.ai.mit.edu (Michael I Bushnell) (06/25/91)
In article <BUZ.91Jun24165007@buz.eng.ready.com> buz@@eng.ready.com (Greg Buzzard) writes:
What is the reason for the mach_port_allcate_name function being in the
kernel interface? It seems to me that all it does (over and above
what mach_port_allocate does) is make implementations more difficult.
That is, this is the only reason that I can think of that would cause
me to use a splay tree in the port name lookup facitily.
Similarly, it seems that it would have been nice if
mach_port_insert_right was restricted to only insert rights using a
"name" that had been previously extracted.
Here are two examples of this utility:
A server can arrange, with mach_port_allocate_name, to have port
rights correspond directly to addresses of relevant data structures in
its address space, saving a table lookup.
The GNU emulator uses mach_port_insert_right to copy some port rights
to a child when a fork happens. It wants to insert them into the
child under the same name they had in the parent. Your condition
would prevent them from being inserted at all.
-mibRichard.Draves@cs.cmu.edu (06/26/91)
Excerpts from netnews.comp.os.mach: 24-Jun-91 mach_port_allocate_name Greg Buzzard) (687) >What is the reason for the mach_port_allcate_name function being in the >kernel interface? It seems to me that all it does (over and above >what mach_port_allocate does) is make implementations more difficult. >That is, this is the only reason that I can think of that would cause >me to use a splay tree in the port name lookup facitily. >Similarly, it seems that it would have been nice if >mach_port_insert_right was restricted to only insert rights using a >"name" that had been previously extracted. >Am I missing some implicit rationale for this interface? In fact, the full 32-bit space for port names is commonly used. Some important servers make use of mach_port_allocate_name to allocate ports which will represent an object, where the name of the port is the address of the object in their address space. When they receive a request message, the conversion from port to object doesn't need a hash table; it is just a cast. If the Mach 3.0 interface were redesigned in a vacuum, it would still be a tough call whether this functionality warrants the increased implementation complexity. However, in real life two factors swayed me. First, earlier versions of Mach support a full 32-bit name space, and backwards-compatibility was an important concern. Second, I was able to design the data structures so the implementation complexity did not slow down the common cases where the splay tree is not accessed. (In the fast cases, port names are an index into an array, and after the array bounds check nothing more need be done.) Rich
buz@@eng.ready.com (Greg Buzzard) (06/26/91)
In article <MIB.91Jun25133212@geech.gnu.ai.mit.edu> mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes: In article <BUZ.91Jun24165007@buz.eng.ready.com> buz@@eng.ready.com (Greg Buzzard) writes: What is the reason for the mach_port_allcate_name function being in the kernel interface? ... Similarly, it seems that it would have been nice if mach_port_insert_right was restricted to only insert rights using a "name" that had been previously extracted. Here are two examples of this utility: A server can arrange, with mach_port_allocate_name, to have port rights correspond directly to addresses of relevant data structures in its address space, saving a table lookup. Yuck! :-) I don't see how you can resolve the possibility of multiple servers that might want to do this with the same virtual addresses. If you pass the port numbers as ints (so the kernel wont remap them for the receiver) then you lose the ability to lookup the object on the receiving side, right? Is this trick good for only a single server? Feel free to point me at some sample code to look at for further "enlightenment", if you want... The GNU emulator uses mach_port_insert_right to copy some port rights to a child when a fork happens. It wants to insert them into the child under the same name they had in the parent. Your condition would prevent them from being inserted at all. Ah, yes... good point. So I guess sparse port spaces are unavoidable. Thanks folks, -- Greg Buzzard internet: buz@eng.ready.com Ready Systems 470 Potrero Ave. phone: 408/736-2600 Sunnyvale, CA 94086
Richard.Draves@cs.cmu.edu (06/26/91)
Excerpts from netnews.comp.os.mach: 26-Jun-91 Re: mach_port_allocate_name Greg Buzzard) (1645) > A server can arrange, with mach_port_allocate_name, to have port > rights correspond directly to addresses of relevant data structures in > its address space, saving a table lookup. > >Yuck! :-) I don't see how you can resolve the possibility of multiple >servers that might want to do this with the same virtual addresses. Every task has its own port name space, so different servers can allocate ports with the same name/address for the receive rights. Rich