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