Comparing IPC and capability invocation
jtl at ira.uka.de
Fri Dec 12 14:34:31 CET 2003
On Dec 11, 2003, at 18:57, Jonathan S. Shapiro wrote:
> In EROS, the corresponding invocation would be:
> file_capability->invoke(operation-id, ... other args ...)
> That is, the fact that "file" is not a kernel-supported object does
> The "file_capability" contains within it a pair of the form:
> (process-id, server-defined-bits)
> The server-defined-bits portion cannot be examined by the client. It is
> provided to the server during invocation. The server can interpret
> bits in any way desired: as an object id, as a facet id, as permission
> bits, as some mix of these.
> The presence of these bits does not preclude invocation of the server
> qua server; the server merely assigns to itself an arbitrarily chosen
> value of "server-defined-bits" to name the server itself.
How does the EROS model support multiprocessor object invocation?
Given that L4 invocations directly address threads, a client can
address a server's CPU-local thread, independent of the object type.
The thread space provides a dimension of optimization which is
independent of the object identification space. Thus a client can
load-balance (by first choosing a client thread on the same CPU as the
server thread), or the client can let the server load-balance (and thus
choose the server thread which executes on the same CPU as the client
thread). This is generally necessary on ia32 hardware for high speed
communication, due to rather expensive xCPU IPC. With non-ia32
hardware (such as the dual core MIPS SiByte), xCPU IPC can be blazing
fast, and user-level processes optimized for the processor can choose
to support xCPU IPC. If the kernel were to distribute object
invocations to a server's per-CPU threads, it would be implementing a
policy, and one which might not satisfy the user tasks.
I'm highlighting this multiprocessor problem as an example of why one
might want to directly address thread IDs, rather than object IDs. My
intuition is that separating the thread ID space from the object ID
space offers more versatility. I can imagine solutions for EROS, such
as allocating one capability per processor, but this overloads the
concept of a capability, does it not?
More information about the l4-hackers