[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: servers that implement multiple interfaces
From: |
Jonathan S. Shapiro |
Subject: |
Re: servers that implement multiple interfaces |
Date: |
Wed, 12 Oct 2005 13:32:39 -0400 |
On Wed, 2005-10-12 at 18:33 +0200, ness wrote:
> How are those treated? (Maybye that's a silly question, I apologize if
> so, but my hurd world began/begins at hurd/l4).
I think you are asking: "How are they handled in Hurd?", but here is a
quick answer for EROS/Coyotos. There are three ways, but a simple
decision tree.
Decision 1: Do the interfaces need to be individually revocable?
If so, then you need a wrapper so that you can do revocation.
In practice, it becomes convenient to use the wrapper data word
that I have previously described to store a pointer that is
the server virtual address of the object.
The server can run one thread or multiple threads. This is
an orthogonal decision.
Decision 2: How many total distinct interfaces?
If it will fit, the, you can use the endpoint cap
protected payload. Otherwise, you fall back to a wrapper.
In Coyotos, it is clear that we need something that serves the role of a
wrapper, but it is not yet clear how we will choose to implement it.
There are currently two proposals:
1. Use a wrapper object, as we did in EROS.
2. Provide an endpoint forwarding mechanism, so that you can build
an arrangement where each revocable object has a unique endpoint.
This endpoint supplies the data word, but transparently forwards
all rendezvous responsibilities to a per-server endpoint.
Really, these are just two representations of the same trick. It is
purely a matter of which one requires less mechanism and/or complexity
in the implementation.
shap