[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gnumach and I/O
Re: Gnumach and I/O
Sun, 5 Mar 2006 10:34:44 -0500
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
> - 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)?
glibc's ioperm() (sysdeps/mach/hurd/i386/ioperm.c) should just work then,
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
> 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. :-)
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... :-/
- Re: Gnumach and I/O,
Thomas Schwinge <=