l4-hurd
[Top][All Lists]
Advanced

[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




reply via email to

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