Hurd IPC

[Neal H. Walfield]

> So, the plan is no longer to build a Mach-like layer on top of L4 that
> will provide synchronous message passing, etc.? I saw a reference to
> such a layer called libmom (Microkernel Object Model) in the L4-Hurd
> archives.

That was never my intention.  The Hurd should not require Mach
semantics, however, there is not reason that it should not use them to
meet its requirements.  In the Hurd, the primary users of ports are
libports and glibc.  To understand the actual requirements, we must
understand what these applications are currently doing with ports.
The short answer is managing handles to objects; the handles just
happen to be ports.

With this in mind, let's consider what type of operations we (as
clients) want on to do an object.  To help conceptualization an object
handle, we can think of it as a more flexible file descriptor.
Interesting operations include: opening and closing an object
(i.e. getting a handle), performing operations on it (e.g. read and
write), coping it (e.g. dup), passing it to others (e.g. sendto and
fork) and detecting if the server backing it disappears.

In Mach, we use a send right to represent a reference to an object,
i.e. a handle.  When a user does an open, the server creates a receive
right and returns a send right to user.  The send right can be used to
perform operations on the actual object.  The server is able to
authenticate the user of the handle as ports cannot be forged.
Copying the send right around is a matter of using the provided Mach
interfaces; something transparent to the actual server.  To detect
server death, Mach provides dead name notifications.

As we can see, the required semantics can be easily implemented using
Mach, however, as we were careful to not define the required semantics
of handles in terms of Mach ports, we can envision other
implementations.

On L4, unlike on Mach, a receiver knows who the sender is (Mach knows
what port the message is dequeued from--this is significantly
different).  This small feature allows a server to provide all of the
require functionality.  When a client does an open, the server creates
a tuple consisting of the server's communication thread (normally
there is only one per server but not necessarily), the client's task
id and a handle id.  The sever returns the handle id to the client.
When the client wishes to communicate further or ask the server to
perform operations on the object, it sends a message to the server's
communication thread and specifies the handle id.  The server can
authenticate the request by looking up the handle id and seeing if the
sender is a known user.  This later feature prevents forging handle
ids.

To share or transfer handles ids to other tasks, a task must contact
the server and request that it "share" a handle with another task.
The server cannot implicitly copy the handle as the target task may
not want it (if it did, the caller would be able to perform a DOS).
This problem is avoided on Mach as a task either receives port rights
either via messages or they are inserted by someone who has the task's
task port.  The client must then send a message to the intended
receiver telling it to contact the server and claim the handle.  When
the server receives the claim message, the task is granted access to
the object.

Dead name notifications can also be performed.  In this case, the
client asks the server for the notification instead of Mach.  This is
clearly unguaranteed: the server may segfault.  To prevent this a less
timely, however, guaranteed notification is also provided: the client
may contact the task server to request a task death notification.  If
it receives it, it can do the necessary cleanups.

Lack of steam is forcing me to terminate this email.  There are other
details that I have left out.  I will revisit these later either in
the full write up or in response to specific questions (but try to
make the subject of the message appropriate).