bug-hurd
[Top][All Lists]
Advanced

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

Re: Gnumach and I/O


From: Samuel Thibault
Subject: Re: Gnumach and I/O
Date: Thu, 9 Mar 2006 01:37:18 +0100
User-agent: Mutt/1.5.9i-nntp

Hi,

Thomas Schwinge, le Sun 05 Mar 2006 10:34:44 -0500, a écrit :
> On Sun, Jan 08, 2006 at 06:50:40PM +0100, Samuel Thibault wrote:
> > device "iopl" has a bunch of registers: speaker, game port, sound,
> > printer, video, and gives read-only access to any i/o port.
> 
> My vote is to remove the `iopl' device.

I'd vote for this too :)

> It's currently used by X's somethingReadBIOS() function, but it should
> be easy to switch that over to something more reasonable.  Are there
> other known users of this device?

Not to my knowledge.

> > - gnumach2 provides i386_io_perm_create(master, from, to, &new_io_perm)
> > for creating an "i/o range" and i386_io_perm_modify(task, io_perm,
> > enable) for enabling/disabling access to the range.
> 
> > - glibc usually provides a mere ioperm(base, count, enable) that just
> > sets/clears bits, but how to implement that easily with the two
> > interfaces above?
> 
> > - We backport the gnumach2 interface to gnumach1. It shouldn't be hard,
> 
> Samuel, could you please evaluate backporting the code from OSKit/Mach,
> i.e.  Marcus's work from
> <URL:http://lists.gnu.org/archive/html/bug-hurd/2001-10/msg00186.html>,
> <URL:http://lists.gnu.org/archive/html/bug-hurd/2001-12/msg00074.html>,
> <URL:http://lists.gnu.org/archive/html/bug-hurd/2002-02/msg00231.html>,
> <URL:http://lists.gnu.org/archive/html/bug-hurd/2002-03/msg00088.html>,
> and the later changes from gnumach's trunk (if any)?

Well, I actually did it before writing this mail, that's why I said that
it shouldn't be hard :)

> glibc's ioperm() (sysdeps/mach/hurd/i386/ioperm.c) should just work then,
> <URL:http://lists.gnu.org/archive/html/hurd-devel/2002-03/msg00027.html>.

Indeed. But the interface looks strange to me. It defines two
calls: i386_io_perm_create() for creating an "io range", and
i386_io_perm_modify() for actually enabling/disabling it.

When I had a first look at this, I thought that the idea was that these
"io ranges" would give io permission when i386_io_perm_modify is used
for actually enabling them, and until they are destroyed ; i.e. just
like how gnumach 1's i/o permissions are supposed to work (but as I
said in a previous mail, it is bugged: if a task asks for i/o access
to speaker+timer (represented by some port A), then asks i/o access to
timer (port B), and then drops its i/o access to speaker+timer (port
A), access to timer (port B) doesn't work! (because the i/o bitmap is
blindly modified when dropping port A) ).

But this is not the case: with gnumach2, after creating an "io range",
enabling it, and destroying it, the io permission remains, so that the
current implementation of ioperm() can indeed work without a need for
port leak.

> That interface [(ioperm())] could / should in turn then be used by
> external programs like X or pciutils to equip them with the needed
> rights to access I/O ports.

Then why splitting ioperm()'s work into two i386_io_perm_create()
and i386_io_perm_modify() calls if people should use ioperm()
rather than Mach calls? Couldn't gnumach just provide an
i386_io_perm_modify(ipc_port_t master_port, io_port_t from,
io_port_t to, boolean_t enable) call instead of the current two fancy
calls? (I'm ready to write a patch for this)

Regards,
Samuel




reply via email to

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