[Top][All Lists]
[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
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, (continued)
Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Jonathan S. Shapiro, 2007/01/07
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Marcus Brinkmann, 2007/01/07
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Pierre THIERRY, 2007/01/07
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Marcus Brinkmann, 2007/01/07
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Pierre THIERRY, 2007/01/07
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Jonathan S. Shapiro, 2007/01/08
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Pierre THIERRY, 2007/01/08
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack,
Jonathan S. Shapiro <=
Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Marcus Brinkmann, 2007/01/08
Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Pierre THIERRY, 2007/01/08
Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Marcus Brinkmann, 2007/01/08
Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Pierre THIERRY, 2007/01/08
Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Marcus Brinkmann, 2007/01/08
Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Pierre THIERRY, 2007/01/08
Opaque storage, Jonathan S. Shapiro, 2007/01/08
Re: Opaque storage, Marcus Brinkmann, 2007/01/08
Opaque storage, Pierre THIERRY, 2007/01/09
Re: Opaque storage, Marcus Brinkmann, 2007/01/09