Re: Coyotos vs. EROS

[Jonathan S. Shapiro]

On Fri, 2005-10-28 at 10:03 +0200, ness wrote:
> Justin Emmanuel wrote:
> > OK! I give up.
> > 
> > 1) What is an endpoint?
> > 
> > Once I know that I will know what a capability or an IPC endpoint is.
> > 
> An endpoint is a replacement for thread ids, at least in l4. I don't 
> know what this is good for in coyotos, actually eros had start 
> capabilities. Maybye sth. related to events (asynchronus IPC).

Umm. Not exactly. Let me try to explain endpoints a little better.

Any time you do an IPC, there is a rendezvous between the sender and the
receiver. Also, there is the possibility that the sender may block
because the receiver is busy, so there is a queue.

At this very low level of abstraction, we can think of an IPC as a
message that is sent to a queue and (assuming that no blocking occurs)
simultaneously received from that queue. In this way of looking at
things, it is the *queue* that is the target of the IPC.

This queue is the endpoint.

In Mach, EROS, and L4, endpoints are unified with processes. Every
process has a receive endpoint as part of the process state. The receive
phase of the operation does not need to name this endpoint explicitly,
because it is implicitly understood that receives always happen on the
receive endpoint of the receiving process.

Similarly, in Mach, EROS, and L4 the destination of an IPC is usually
said to be the thread or process (L4: the thread id; Mach: send port
names destination process; EROS: start capability names destination
process). Here again, we are really naming the receive endpoint
implicitly.

In L4, the specification of thread id had some added details that
allowed IPC to go to some member thread in a task. There were several
unfortunate aspects of that design, but the big three were (1) the
requirement for a buddy system allocator in the task table and (2) the
fact that the client can see that the server is multithreaded, and (3)
some awkwardness in redirecting and forwarding messages -- in particular
for deceiting IPC. I am not entirely clear about the history, but I
believe that issue (1) was eventually addressed.

In EROS, the unification of endpoints with the target process made it
irritating to build multithreaded services. Also, there were some
implementation complications from resume keys that would require some
serious explanation before I could make them sensible.

I *think* (but I am not sure) that I was the first one to suggest that
we should make the endpoint into a first class object. If this is done,
then the SendAndWait primitive becomes

        SendOn {send endpoint cap}, payload
        AndThenReceiveOn {receive endpoint cap}, receive spec

It is simply more flexible. Coyotos is sticking with this design. If I
understand correctly, L4.sec has gone back and forth a few times on
whether every process should have a receive endpoint associated with it
at the data structure level. I do not know where the current resolution
of this stands in their design.


shap