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