bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Neal H. Walfield
Subject: Re: Do we want a server on `/servers/machine' (or similar)?
Date: Sat, 12 May 2007 10:39:20 +0200
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Fri, 11 May 2007 00:50:43 +0200,
Thomas Schwinge <tschwinge@gnu.org> wrote:
> #v+
> 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)
> { 
>   kern_return_t err;
> 
> [Do some checks on PORT.]
> 
>   err = i386_io_perm_create (devmaster, from, to, io_perm);
> 
>   return err;
> }
> #v-
> 
> ... to serve invocations of `i386_io_perm_create' on T and -- after the
> needed checking -- pass the request to the device-master port, invoking
> `i386_io_perm_create' on there.  This works.
> 
> But there is one problem.  If the requestee (the program that invoked
> `i386_io_perm_create' on T) terminates, the server T won't (tell the
> kernel to) destroy the resources that have been allocated by invoking
> `i386_io_perm_create' on the device-master port.

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).

>  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.

> 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.

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).

Neal





reply via email to

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