Mach 3 Kernel Principles
9
Elements
resource manager executes within the kernel; the second is that of a supplier of resources
for whom the resource manager is the task itself.
With the exception of the task’s virtual address space, all other system resources are ac-
cessed through a level of indirection known as a port. A port is a unidirectional communi-
cation channel between a client who requests a service and a server who provides the
service. (If a reply is to be provided to such a service request, a second port must be
used.) The service to be provided is determined by the manager that receives the message
sent over the port. It follows that the receiver for ports associated with kernel provided
entities is the kernel and the receiver for ports associated with task provided entities is
the task providing that entity. For ports that name task provided entities, it is possible to
change the receiver of messages for that port to be a different task. A single task may
have multiple ports that refer to resources it supports. For that matter, any given entity
can have multiple ports that represent it, each implying different sets of permissible oper-
ations. For example, many entities have a name port and a control port (sometimes called
the privileged port). Access to the control port allows the entity to be manipulated; ac-
cess to the name port simply names the entity, for example, to return statistics.
There is no system-wide name space for ports. A thread can access only the ports known
to its containing task. A task holds a set of port rights, each of which names a (not neces-
sarily distinct) port and which specifies the rights permitted for that port. Port rights can
be transmitted in messages; this is how a task gets port rights. A port right is named with
a port name, which is an integer chosen by the kernel that is meaningful only within the
context (port name space) of the task holding that right.
Most operations in the system consist of sending a message to a port that names some
manager for the object being manipulated. In this document, this will be shown in the
form:
object → function
which means that the function is to be invoked (by sending an appropriate message) to a
port that names the object. Since a message must be sent to some port (right), this opera-
tion has an object basis. However, not all entities are named by ports and so this is not a
pure object model. The two main non-port right named entities are port names/rights
themselves, and ranges of memory. (Event objects are also named by task local IDs.) To
manipulate a memory range, a message is sent to the containing virtual address space
(named by the owning task). To manipulate a port name/right (and, often, the associated
port), a message is sent to the containing port name space (named by the owning task). A
subscript notation,
object [id] → function
is here used to show that an id is required as a parameter in the message to indicate
which range or element of object is to be manipulated. This form is also used for a hand-
ful of operations in which a privileged port (the host control port) must be supplied as
well as the object to be manipulated for the sake of verifying privilege for the operation.