🚀 go-pugleaf

I am writing some server programs that deal with multiple clients.  Each
client (typically) has send rights to some ports owned by the server.
I've noticed that when the server task receives a port-death notification
message, the notify_port member of the message differs by one from the
port_name_t variable held by the server.  Since this behavior appears
consistent, I simply add 1 to the value supplied in the message (after
casting to 'int'), and use this value as the key in a table search for
the client connection that has been broken.  But why the difference?
What is the port_name_t supplied in the notify message supposed to mean?

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

While in the case mentioned above, my ad hoc solution of 'add one' seems
to work, another server I am writing has not yet yielded such an empirical
transform.  This is an out-of-kernel server to implement System V shared
memory semantics.  This server uses the netmemoryserver to supply the
shared memory.  The SysV "shmget" routine is implemented by a
netmemory_create() performed by the server; it retains rights to the
paging_object and control_port supplied. A unique 'shmid' (shared memoryID)
is created by the server and returned.  The SysV "shmat" (attach) function is
implemented by having the server perform a vm_map() operation on the
client's task port.  The "shmat" function supplies as argument the shmid
created during the shmget; this ID is used as a key for a table search

The problem arises in the SysV "shmdt" (detach) function.  The sole
argument specified in the SVID is the virtual address of the memory to
detach from the client's address space.  How can the server determine
which of many netmemory objects is to be detached?  [The PID, UID and GID
of the caller is supplied by our kernel layer to the server, along with
the caller's task port.  This is not enough, because processes may attach
a shared memory segment and then fork.  The memory is shared between parent
and child.  We would like not to clutter up the kernel by adding an kernel
message to the server on forks.  Duplicating the SysV inheritance behaviour
is of course no problem; during the vm_map() operation the server specifies
VM_INHERIT_SHARE.]

My current, partial, solution is to use vm_region() with the supplied
virtual address against the client's task port.  This gives the server
the size of the object, which completes the information necessary to
perform a vm_deallocate() on the client's behalf to detach the memory.

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?

Thanks,

Bill Kerr
Tektronix
billk@orca.wv.tek.com