Re: Gnumach and I/O

[Thomas Schwinge]

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...  :-/