On Sun, Jan 08, 2006 at 06:50:40PM +0100, Samuel Thibault wrote: > Just for reminding what's on the bts: > > [...]
Samuel, thanks for the work you've done so far! :-D > Well, actually, gnumach2 does indeed set i/o port permissions on tasks > rather than on threads. [ Patch ... (TSS is now task-based) ] makes > gnumach1 behave that way too. Yes, that's the way to go, I'd say. > But what about the interface? > > - gnumach1 provides i386_io_port_add(thread, dev) which adds > device-defined ports to allowed ones: for instance, device "kd" has video > registers (I'd add speaker ports though, since they are used too) ; > 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. 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? > - 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)? 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>. That interface 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. > but the patch would get quite bigger. I don't mind applying a big patches, as long as it's understandable where the bits are coming from, which would certainly be the case if it's based on the OSKit/Mach work. :-) Regards, Thomas P.S. During a discussion on IRC, Roland told me that OSKit/Mach, i.e. gnumach's trunk, already contains most of the clean-up we're currently applying to gnumach-1-branch... Nobody told me... And myself, I also didn't think about having a look at the OSKit/Mach tree... :-/ _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
