[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
capability interface for idl4
From: |
ness |
Subject: |
capability interface for idl4 |
Date: |
Tue, 04 Oct 2005 21:54:50 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.6 (X11/20050813) |
To get the abstraction we need, there has to be an capability interface
in idl4. This means, we can say idl4 "here is the cap, give it to xyz",
and idl4 generates the stub. But I'm a little confused about what ways
of sending caps we have and what is needed in idl4. I found the
following ways of sending a capability:
1. simple handle passing
We simply pass the handle for authentication. This means, the
server we pass the handle provides the cap.
2. capability copying
The process a has a handle to a cap provided by s and wants to
give the process b the right to use this cap. This is done via
the cap server.
3. sth. mysterious I called capability object passing
The client calls a server and gets as result a newly created
handle to a cap. Can e.g. be found in hurd_pm_container_create
(better to see with the patches by racin).
Looks nice, but is this right this way? And, do we need the second one
to be provided by idl4? I say, usually the server will not trust its
client and this it's useless, as the server will not use the new handle.
--
-ness-
- capability interface for idl4,
ness <=
- Re: capability interface for idl4, Neal H. Walfield, 2005/10/04
- Re: capability interface for idl4, Matthieu Lemerre, 2005/10/04
- Re: capability interface for idl4, Jonathan S. Shapiro, 2005/10/07
- Re: capability interface for idl4, Matthieu Lemerre, 2005/10/08
- Re: capability interface for idl4, Jonathan S. Shapiro, 2005/10/08
- Comparing "copy" and "map/unmap", Jonathan S. Shapiro, 2005/10/08
- Re: Comparing "copy" and "map/unmap", Matthieu Lemerre, 2005/10/09
- Re: Comparing "copy" and "map/unmap", Marcus Brinkmann, 2005/10/09
- Re: Comparing "copy" and "map/unmap", Matthieu Lemerre, 2005/10/09
- Re: Comparing "copy" and "map/unmap", Jonathan S. Shapiro, 2005/10/09