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

[Thomas Bushnell BSG]

On Fri, 2007-05-11 at 00:50 +0200, Thomas Schwinge wrote:
> [Remove hurd-devel.]
> 
> 
> Hello!
> 
> In the server T (`/servers/ioperm') I essentially have...
> 
> #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.  This is because there
> is no association between the port `port' and these resources.  How to
> establish such a relationship?
> 
> If `port' becomes dead, `io_perm' should be deallocated as well, but how?

Um, well, you could keep track of the relationship, and establish the
rule that a user of i386_io_perm_create sent to this special server must
keep the request port open as long as they want the mapping to stay
alive.  

This suggests that it's not the best idea to reuse the name since the
semantics are shifting, which perhaps also makes an opening to have a
more generic interface.  (On the other hand, other processors don't have
anything like 386 IO registers, so maybe it's not worth it.)

As for separating the memory access and the IO ports, is there any
reason to want to combine them?

Thomas

signature.asc
Description: This is a digitally signed message part