Comparing IPC and capability invocation

[Joshua LeVasseur]

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 
> not.
> 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 
> these
> 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?

-Josh