[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gnumach and I/O
Re: Gnumach and I/O
Thu, 9 Mar 2006 01:37:18 +0100
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
> 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,
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
> 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)