Re: A comment about changing kernels

[Bernhard Kauer]

On Mon, Oct 31, 2005 at 10:05:33AM -0500, Jonathan S. Shapiro wrote:
> In order to implement a sessionless RPC protocol, every CALL (the first
> IPC) must transmit an endpoint capability. This endpoint capability will
> later be used by the server to perform a RETURN (the 2nd IPC).
...
> First question: is this set of statements consistent with your
> assumptions about how sessionless RPC would work?

Yes, I assume that a return endpoint has to be send with every CALL.


> we may safely conclude that these CALL/RETURN patterns
> describe the overwhelming majority of IPCs -- all of the other patterns
> taken together accounted in EROS for less than 1% of all dynamic IPCs.

Is the CALL/RETURN pattern used for capability delegation (giving an cap
to another party) or only for usage of these capabilities?


> As we considered the session/sessionless issue in Coyotos, I became
> convinced that using the protected payload as a session ID would not
> scale well, and also presents certain challenges for bootstrapping and
> isolation.

Interesting. What are the scalability and isolation problems with badges?


> We have therefore concluded that Coyotos needs to support capability
> registers in addition to C-spaces, and that in the normal case the send
> and receive endpoints will live in these registers.

Ok, thats a valid optimization.


> It involves a cache-aligned four-word move from one process to the other,
> using a scaled index addressing mode using the respective process structure
> pointers as base pointers.

This is a cache miss and perhaps a TLB miss since you have to touch the process
structure (I assume a thread/task split like in L4). 

But don't you allow the revocation of this capability later?


> I am *guessing* that this is significantly lower than the cost that you
> anticipate for the MAP operation.
>
> Second question: do you agree that this difference in designs would
> largely explain our differing views about the costs of a sessionless
> protocol?

Yes, but up to now I am not convinced that you can build a revocable copy
with just a single cache miss.


> If the kernel does not support the sessionless protocol, then the server
> must execute the lookups necessary to map from session identifiers to the
> appropriate endpoint capabilities. The cache and TLB misses associated
> with this activity must be accounted as part of the IPC costs in order
> to make an accurate comparison.

The session-id -> return-endpoint lookup in user-level could be the identity
function, since the server is free to manage the badges. The following
capability-space lookup could be more expensive, but this is optimizable
with capability registers...


> And in fact, if you look at the EROS window system, you will discover
> that it is sessionless. So is our current ethernet driver (though this
> one needs to change).

Both components are session based in DROPS.


Thanks,

    Bernhard