🚀 go-pugleaf

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