Re: Do we want a server on `/servers/machine' (or similar)?

[Thomas Schwinge]

Hello!

On Sat, May 12, 2007 at 10:39:20AM +0200, Neal H. Walfield wrote:
> At Fri, 11 May 2007 00:50:43 +0200,
> Thomas Schwinge <tschwinge@gnu.org> wrote:
> > kern_return_t
> > S_i386_io_perm_create (mach_port_t port, io_port_t from, io_port_t to,
> >                        mach_port_t *io_perm)

> So if I understand correctly, the client has access to PORT (the
> receive right of which is held by the server) and (after calling this
> function) access to IO_PERM (the receive right of which is held by the
> kernel).

Correct.  PORT will be gotten by looking up `/servers/io_perm'.


> >  This is because there
> > is no association between the port `port' and these resources.  How to
> > establish such a relationship?
> 
> The server can request a deadname notification on PORT.

Yes, but that would require keeping some state in the server, which I
wanted to avoid, because...

> > If `port' becomes dead, `io_perm' should be deallocated as well, but how?
> 
> Why does the server need to retain access to IO_PERM?  Once the client
> has the cap, can't the server can deallocate its copy.

..., because there is absolutely no need for the server to keep access to
IO_PERM: as I described in another email of mine, I explicitly want to
_move_ the capability away from the server to the requestee.


> You can do this by explicitly replying to the client and then
> returning MIG_NO_REPLY or you could change the interface to make the
> IO_PERM return parameter a MACH_MSG_TYPE_*MOVE*_SEND (I suspect that
> it is currently a MACH_MSG_TYPE_*COPY*_SEND).

Okay.  Now I need to go reading more about MIG.  Or someone else comes up
with how to do that in practice (and then I nevertheless go reading more
about MIG).


Regards,
 Thomas

signature.asc
Description: Digital signature