[Top][All Lists]

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

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

From: Thomas Bushnell BSG
Subject: Re: Do we want a server on `/servers/machine' (or similar)?
Date: Thu, 10 May 2007 19:32:31 -0700

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

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?


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

reply via email to

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