At Fri, 11 May 2007 00:50:43 +0200,
Thomas Schwinge <[EMAIL PROTECTED]> 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
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
