Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!gate.ready.com!gate.ready.com!ready!buz From: buz@@eng.ready.com (Greg Buzzard) Newsgroups: comp.os.mach Subject: Re: mach_port_allocate_name Message-ID: Date: 26 Jun 91 01:20:41 GMT References: Sender: usenet@ready.eng.ready.com (Usenet Administrator) Organization: Ready Systems, Smoggyvale CA Lines: 40 In-Reply-To: mib@geech.gnu.ai.mit.edu's message of 25 Jun 91 18:32:12 GMT In article mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes: In article 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