Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!andrew.cmu.edu!<UNAUTHENTICATED>+
From: Richard.Draves@CS.CMU.EDU
Newsgroups: comp.os.mach
Subject: Re: port name matching
Message-ID: <gZZbiya00hYPN1GGBZ@cs.cmu.edu>
Date: 25 Dec 89 19:57:50 GMT
References: <5720@orca.wv.tek.com>
Sender: rpd@M.GP.CS.CMU.EDU
Distribution: na
Organization: Carnegie Mellon, Pittsburgh, PA
Lines: 56
In-Reply-To: <5720@orca.wv.tek.com>

Excerpts from netnews.comp.os.mach: 24-Dec-89 port name matching -for i.
s. command@orca. (2988)

> In general, what is the algorithm for correlating port names supplied
> in notifications and reports with the port names held by the task?

The port name supplied in a port-deleted notification is the name of the
erstwhile send right.  When a port is destroyed, because its receive
right is deallocated, the kernel deallocates any remaining send rights
and notifies the holders of those rights with port-deleted notifications.

It sounds like you are expecting the notification to be generated before
the kernel actually generates it, so that when you expect a notification
for port N you are actually getting the notification for the previous
port, N-1.  (In Mach 2.5, the kernel picks names for port rights
sequentially.  This is an implementation choice, and is subject to
change.  The kernel can pick any unused name for a new port right.)  I
don't understand your scenario, however.  You say the clients have send
rights for ports owned by the server, and then go on to talk about
notifications received by the server.


> Vm_region() also supplies a port name corresponding to the paging object of
> the region.  But this value differs from the value of the port_name_t
> variables retained by the server.  How can I use the information supplied
> by vm_region() to identify the netmemory_object in question?  In what
> "name space" are these port names valid?

The vm_region() call returns send rights for a name port.  The external
memory management interface deals with three kinds of ports.  The memory
object is represented by a memory object port, or memory_object_t.  The
server (netmemoryserver in this case) holds receive rights for the
memory object port.  You supply send rights to this port in vm_map()
calls.  When a kernel first encounters a memory object in a vm_map()
call, it creates a control port (memory_object_control_t) and name port
(memory_object_name_t).  If a memory object is mapped into address
spaces on multiple machines, a single object will have multiple control
and name ports.  The kernel has receive rights for the control and name
ports.  The kernel sends messages (from the memory_object.defs
interface) to the memory object port.  The server sends messages (from
the mach.defs interface) to the control port.  Messages aren't sent to
the name port; it is used for identification purposes in vm_region()
calls.

The control port returned by netmemory_create() is different from the
memory object control port for which the kernel holds receive rights. 
The netmemoryserver has receive rights for the control port from
netmemory_create().  The control and name ports owned by the kernel
haven't yet been created at the time of netmemory_create(); that doesn't
happen until somebody maps the object.

One possibility would be to use vm_region() immediately after vm_map(),
to find out what the name port is.  Then you can make use of the name
port from later vm_region() calls.

Rich