Re: video mem access with oskit-mach

[Thomas Bushnell, BSG]

Roland McGrath <roland@gnu.org> writes:

> One annoyance that's not really a problem in practice is the inheritance
> (or lack thereof).  The Linux `ioperm' model applies to all threads in the
> process (I think) and is preserved across exec (so the documentation says).
> Conversely i386_io_port_add works on a single thread, so it's not pretty
> for one `ioperm' call to affect all current and future threads in the
> process, or the future thread after an exec.  

It seems to me that it should *certainly* be task-based, since io
ports and memory are very close analogues.  It's obvious why they took
the easy way out (because the data structure on the 386 is a
tss-specific thing).  But it's wrong that way.  It should be
task-based. 

> The way the current interface works (not supported in oskit-mach) is that
> you pass a device_t (i.e. a kernel device port from device_open) and that
> refers to a set of io ports.  This has the nice property that you can have
> a capability for a subset of the io ports that you can pass around.  This
> could make it possible e.g. to have a root-owned translator allow a
> non-root X server to get a capability for a limited set of io ports, just
> as a remapping store translator could allow a limited subrange of physical
> memory from the "mem" device.

This is a clever interface; I like it.  It would be cool to preserve
the idea here.  But overloading the notion of device ports, as you
point out, is the wrong way to go about it.  It should be some new
kind of capability port.