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
_______________________________________________
L4-hurd mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/l4-hurd
