Re: EROS/Coyotos fault handers vs l4 pager hierarchy

[Matthieu Lemerre]

Marcus Brinkmann <address@hidden> writes:

> At Fri, 21 Oct 2005 11:17:45 +0200,
> Matthieu Lemerre <address@hidden> wrote:
>> > We have established in previous emails that there tends to be a
>> > hierarchy of pagers in L4. The root of this hierarchy is privileged
>> > because it is the ultimate source of all pages.
>>
>> I don't think there is such a hierarchy in L4.
>
> [...]
>
>> What is hierarchic, though, is the mapping database of course.
>

[...]

>
> The mapping database is hierarchic, but it is not a concept of L4.  In
> fact, the mapping database is internal to the kernel, it's not exposed
> to the user at all.  

I'd like to correct myself here: what I meant by "the mapping database
is hierarchic" was really "the tree of mappings is hierarchic".  The
fact that the mapping database is the kernel structures which stores
this tree wasn't my point at all.

> It can only be modified implicitely by sending map items over IPC.

Or using unmaps with which you can delete subtrees.


[...]

>
>> > There is no comparable hierarchy in EROS. A fault handler's job is
>> >to repair a page fault or not. Once a COPY is completed, there is no
>> >further dependency on the sender's fault handler. In EROS, the
>> >hierarchy is a matter of storage allocation, not mapping recovery.
>> 
>> I really think that there is no dependency on the sender's fault
>> handler too on L4.  You can have a system which never invokes your
>> pager (like the system I described in my last mails).
>
> I think there is just a misunderstanding here.  The "sender of a page"
> in our Hurd-on-L4 design for example is always physmem.  And any local
> page fault (which can happen because physmem is allowed to revoke
> mappings for internal reorganization) will be forwarded to physmem by
> the local pager.  Thus, there is indeed a direct dependency.

Don't worry, I know how what is implemented works.  I was speaking of
the design I came up in

http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00288.html.

In the current Hurd on L4, physmem has two differents semantical
roles:

-It allocates physical memory

-It acts as a third party for memory transmission.

Whenever a client wants to give some memory to (e.g.) a server, the
semantics of the operation is: "I want to give you memory that you can
use to serve me". The constraints on this memory gift are:

-The gift has to be revocable (the client does not want memory to be
 used against its will)

-But this revocation must not be harmful to the receiver.

>From these observations, I can thing of two classes of solutions:

-Memory is given to and can be trusted by the receiver.  This is what
 the Trusted Buffer Object in EROS does, or what physmem does.
 Physmem is really a trusted third-party for memory transmission.

-Memory is given to the receiver, and there is no guarantee (i.e. the
 "gift" can be revoked at anytime).  This is what is done in general
 in EROS (if the memory is revoked, the objects just disappear), and
 what I think is doable on L4 e.g. for both IO and capability storage
 (for instance with my proposal with the URL above, which I'm going to
 complete.)

Thanks,
Matthieu