Newsgroups: comp.os.mach
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!mintaka.lcs.mit.edu!mib
From: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
Subject: Re: mach_port_allocate_name
In-Reply-To: buz@@eng.ready.com's message of 24 Jun 91 22:50:07 GMT
Message-ID: <MIB.91Jun25133212@geech.gnu.ai.mit.edu>
Sender: news@mintaka.lcs.mit.edu
Organization: Free Software Foundation, Cambridge, MA
References: <BUZ.91Jun24165007@buz.eng.ready.com>
Date: 25 Jun 91 13:32:12
Lines: 25

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.

	-mib

