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 _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://mail.gnu.org/mailman/listinfo/bug-hurd
