[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A comment about changing kernels
From: |
Bernhard Kauer |
Subject: |
Re: A comment about changing kernels |
Date: |
Fri, 28 Oct 2005 21:27:20 +0200 |
User-agent: |
Mutt/1.5.9i |
On Fri, Oct 28, 2005 at 08:03:04PM +0100, Neal H. Walfield wrote:
> > > The problem with L4.sec is the following: It does currently not have
> > > all the operations that we think we need (I am thinking specifically
> > > about efficient capability copy and identification).
> >
> > Just some comments from the L4.sec perspective:
> >
> > The identification via read_badge() is something which will in my
> > opinion be part of the kernel if we do not come with a better solution
> > to solve the multiple capability-parameters problem. Since the read_badge()
> > operation could change, it is currently called "experimental" in the spec.
> >
> > Now to copy(): I know no functional argument to introduce a copy() into
> > L4.sec.
>
> Have you considered this argument [1]? I'd be interested in hearing
> the reactions from the L4.sec perspective.
This concluded, that simulating a copy with a central cap-server is not
possible. You have to call the parent, to do the map for you. In the flat
hierarchy for example this is the server who implements the user-level
object this capability stands for.
> > The only argument is performance. Because mapping (or copy) a
> > return endpoint with every RPC will be too expensive, server protocols
> > will be session based. To establish a new session with a server the
> > server has to be called anyway, which nullifies the advantage of copy().
>
> I don't understand this. Could you please elaborate what "server
> protocols will be session based" means? Perhaps with an illustration
> of what you envision?
Session based mean, that I open a session to a server, send my return endpoint
to it, get perhaps another session-capability from the server and use this
capbility to talk to the server. The server can answer my calls through my
initially send return endpoint.
> > Beside this, both operations are implementable with around 30 lines of
> > code each, which makes these features not very critical.
>
> Which features do you mean exactly?
The copy() and identification operation.
Thanks,
Bernhard
- A comment about changing kernels, Jonathan S. Shapiro, 2005/10/27
- Re: A comment about changing kernels, ness, 2005/10/27
- Re: A comment about changing kernels, Marcus Brinkmann, 2005/10/27
- Re: A comment about changing kernels, Bas Wijnen, 2005/10/27
- Re: A comment about changing kernels, Marcus Brinkmann, 2005/10/27
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/27
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/27
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/27
- Re: A comment about changing kernels, Bernhard Kauer, 2005/10/28
- Re: A comment about changing kernels, Neal H. Walfield, 2005/10/28
- Re: A comment about changing kernels,
Bernhard Kauer <=
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/28
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/28
- Re: A comment about changing kernels, Bernhard Kauer, 2005/10/29
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/29
- Re: A comment about changing kernels, Bernhard Kauer, 2005/10/29
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/30
- Re: A comment about changing kernels, Bernhard Kauer, 2005/10/30
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/31
- Re: A comment about changing kernels, Bernhard Kauer, 2005/10/31
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/31