l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Alternative network stack design (was: Re: Potential use case for op


From: Jonathan S. Shapiro
Subject: Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack
Date: Mon, 08 Jan 2007 09:58:02 -0500

On Mon, 2007-01-08 at 07:52 +0100, Pierre THIERRY wrote:
> Scribit Jonathan S. Shapiro dies 08/01/2007 hora 00:22:
> > 1. Does the *data* in these spaces need to be opaque to the clients?
> > 
> >    Obviously not, since in both cases the service immediately gives
> >    the client read access to the data.
> 
> Yes, I almost used a convoluted expression instead of "opaque memory",
> but it would have probably made my question far less clear.
> 
> I think it would be very beneficial to the discussion if we could settle
> on a term for resources granted with exclusive rights. IIUC, the real
> mechanism is not about opacity, but about the ability to give a
> capability to a resource while losing all authority to this resource,

This will only make it worse, because it is wrong in several respects:

  1. In the ethernet scenario, the TCP/IP stack never held these page
     capabilities in the first place -- they were allocated from the
     space bank by the ethernet driver. So no "giving of capabilities"
     is involved.

     A capability to the **space bank** is transferred, but both sides
     have identical rights on that: the right to allocate pages that
     are exclusively held at the time of allocation.

     One interesting variant of Marcus's proposal is to ignore the
     parent/child relationship of processes, leave the rest of the
     system unaltered, and modify the space bank to remove the
     "exclusively held" condition.

     In this variant, the holder of a space bank would be able to ask it
     for a new capability to any object that is currently allocated by
     that bank (i.e. has been allocated and not yet destroyed). Since
     space banks exist in a resource hierarchy, this ties visibility to
     resource "ownership" (where by "ownership" I mean "authority to
     allocate").

  2. The TCP/IP stack has not given up *all* rights on these pages.
     First, it never *had* any rights by means of page capabilities,
     but ignore that for a moment. The TCP/IP stack still holds the
     right to destroy the space bank, with the effect that all objects
     allocated from that bank are forcibly destroyed.

Also, we mostly *have* terms for this in EROS. If you can identify what
you are trying to describe, I will try to supply the existing terms. Let
us invent only where we need to.

shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100





reply via email to

[Prev in Thread] Current Thread [Next in Thread]