Re: video mem access with oskit-mach

[Roland McGrath]

You got me.  Try it.  I think it should allow no io access, but that's what
I would have thought about gnumach too.

We need a new interface for enabling io ports, because the old CMU style
that gnumach has is just bogus.  It's easy enough to implement a some more
sane RPCs into the kernel, and then we can use that to implement the
`ioperm' interface in libc compatibly with Linux.

Well, maybe the old style sort of makes sense.  But we need some changes.

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.  

So it might be nice to have a kernel interface that is task-based and
affects all threads in the task.  (Incidentally, io port access is
task-based on L4.) 

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.

But the Linux `ioperm' interface is simply that only root can call it and
can (of course) use any and all io ports.  (BSD has an interface called
i386_get_ioperm/i386_set_ioperm that is essentially the same.)

The capability-using interface is certainly more Hurdish.  The reason it's
not implemented in oskit-mach is the overloading of device ports for these
the io access capabilities.  In gnumach there is just some magical table
someplace of what devices correspond to what port numbers, so if you open
"kd" that gets you access to poke the video ports.  That is just nutty.

Perhaps we should have a capability-based interface, but just use special
ports for this instead of device_t's.  e.g., there could be a new call on
the device master port to give you a capability port with the given bitmask
of io ports for access.  Then these ports would be the valid arguments for
i386_io_port_add.