[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnumach and I/O

From: Thomas Schwinge
Subject: Re: Gnumach and I/O
Date: Sun, 5 Mar 2006 10:34:44 -0500
User-agent: Mutt/1.5.6+20040907i

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]