OT: Mach Ports (For the AdaOS folks)

["Warren W. Gay VE3WWG" <ve3wwg@NoSpam.cogeco.ca>]

Dennis Lee Bieber wrote:
> On Thu, 30 Dec 2004 11:30:35 -0500, "Warren W. Gay VE3WWG"
> <ve3wwg@NoSpam.cogeco.ca> declaimed the following in comp.lang.ada:
>>However, IMHO, the microkernel should be small as possible, and
>>leave networking up to the modules outside of it. After all, some may
>>perfer an IPv6 only version of networking for example (in light
>>of China's recent network announcment). In the end, I don't want
>>to be "stuck" with what a brand of microkernel gives me. Just
>>give me the basics and let me decide what is included.

> 	Pardon my slipping in, but...

Discussion is always welcome here.

> 	The more I read in this thread, the more it sounds like my old
> Amiga.

I believe however, there is at least one major difference ;-)

> 	The Amiga EXEC handled only a very small list of functions:
> memory management (the weak point for the Amiga -- flat, shared, memory
> space; no process protection),

This _is_ the major difference. Mach, L4 and other microkernels
provide memory management for you, such that the mk itself,
which is kept very small, is the only piece that runs in "real
mode".

All other modules run in user-mode, preventing security
breaches and corruption from programming errors. Part of the
idea is to keep "real-mode code" to a minimum.

 > task scheduling (including
> semaphore/signal stuff) and process creation, shared library loading
> (note: not the I/O to load the library into memory, but rather the
> linking of a library into system lists), and IPC (message ports:
> essentially linked-lists on which a task may insert a "message" -- a
> structure with a pointer to the task specific data structure; this is
> why the flat memory model was pretty much needed).
> 
> 	All I/O, including keyboard/display, relied upon
> libraries/device drivers which had to be loaded (yes, it sounds
> chicken&egg here -- the Amiga ROMs did contain more than just EXEC, to
> include the core file system handlers, device drivers, etc. but they
> were logically independent units and could be replaced at run-time by
> libraries with identical interfaces).
> 
> 	Everything was done via message ports... An application disk
> read request became a message to the file handler, which then generated
> a message for the disk device driver, etc...

I find that the Mach message interface to be especially
convenient. I think that this one Mach concept is
perhaps the most brilliant part of that work.

Now, one might wonder how a Mach message queue (essentially that
is what it is within the kernel) differs from a UNIX (SysV IPC)
message queue? The differences include the following:

   SysV IPC Message Queue               Mach
   ===============================      =================================
   - can have multiple receivers        - only 1 receiving port per queue
                                          (hence only 1 receiver)
   - can have multiple senders          - same
   - does not have a send-once          - supports a send-once "right"
   - access is limited only by          - you must be "given" a right
     IPC permissions                      (or must have access to the
                                           "task" port that you are going
                                           to acquire a "right")
   - Can configure how much a           - In Mach, I think you can
     queue can hold                        configure between 1-12
                                           "message backlog"
   - Not supported                      - Can force one message (only)
                                          if a queue is full
   - Not supported                      - Dead port notification (when
                                          there are no receivers)
   - The IPC "queue" is removed         - Only the "receiver" port is
                                          destroyed to destroy the queue
   - Messages can be prioritized        - No priorities : FIFO

What makes Mach's port mechanism secure is that you cannot send to
a port, unless you are _given_ a "send-right" (as send-only port to
the message queue). There is one exception WRT the ownership of a
task port (see below).

In essence, there can only be _one_ "receive" right - ie. only
one task can own this receive-right (aka port) (a "task" in
Mach, is the address space, with or without threads). You cannot
duplicate a receive right, but you can "move" it to another task,
by "sending" it to another task, on another message queue.

A send-right OTOH, can be duplicated as often as you like (it only
increments the send reference count on the queue). A send-once
right works the same way, except that you can only use that port
to obviously send a message once (all other duplicated send-once
rights become dead ports, after the message is sent on any of them,
IIRC).

So how does task B get a send right to a port in task A?  It must
have a send-right delivered to task B, by a message. But there is
a bit of a chicken and egg problem here. To solve that,
typically, one module serves as a "name server".

When task B is created by the parent task, a send-right is
"inserted into task B". This allows it to query the
name server; to acquire a send right to A (provided that A has
registered a send right in the name server under some agreed
upon key). The name server duplicates the registered send-right
and "moves" it by message to the caller (client).

The "exception" that I refered to above is this: The parent
"task" receives a send-right of the child task it creates. As
the parent task, it is free to insert ports or to remove ports,
as long as it holds a send-right to that child task's task
port (by which other operating system calls are possible).
Once the parent task closes the child-task's task port
(send-right), it then cannot meddle any further (it cannot
insert/remove any further ports etc.).

So the bootstrap process might make the first "task" (module)
the name server. All other bootstrapped modules would have
a send-right inserted into it, which allows them to contact
the name server. The name server acts as a runtime registry
to accept registrations of services and allows clients to
query and obtain send-rights to these services.

What's neat about this is that it is secure. Knowing a
port number in task A as 87, is of no use to task B. The
port numbers are local to the task, so there is no
global ID that can be used to access the port (service).
A send-right in A as 87, might be 63 in task B, and 45
in task C. The port numbers are only for local task use.
This is one of the problems that the L4 mk has, since its
port IDs are global and can be guessed/determined. Knowing
the ID in L4, gains you access enough to send messages.

I should explain the send-once right: sometimes you
want some follow-up notification, but you only expect
one message. A send-once right guarantees this. This
helps the receiver as well as other possible sources of
the send-once (they all become dead-ports, once someone
uses it to send a message). Thus, a send-once right
guarantees that only one message is queued, and at the
same time, notifies all other cloned send-once rights that
they are now dead (and thus are no longer needed).

Mach 3.x dispensed with a complicated "ownership-right",
which existed in addition to the receiver port in
earlier releases.

I assume that the Mach designers eventually came to the
conclusion that it was a concept that was redundant. Certainly
with its removal, the port concepts become simpler (now when
a receive right is destroyed, all send-rights become
dead ports, notifying all clients of a service, that the
service is now "offline").

Anyway, if you want a deeper understanding of all this good
stuff, there is a book you can get used that does an excellent
job at describing Mach concepts (ports, tasks, threads and
memory objects):

Programming Under Mach:
http://www.amazon.com/exec/obidos/tg/detail/-/0201527391/103-1295179-1094257?v=glance

Unfortunately, it does centre on Mach 2.5, but mentions
Mach 3.x changes (it will cover the important 3.x features).

You will also have to overlook a certain amount of "UNIX
doesn't have threads" discussion, since it was published
in 1992. Otherwise, this is a recommended read for anyone
who is contemplating messing with microkernels, particularly
of the Mach variety.
--
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg