Re: video mem access with oskit-mach

[Roland McGrath]

You are thinking at least as clearly as I am about this, so certainly don't
apologize for doing it out loud!

On further thought I was unsure about some of the same details of my vague
plan that you brought up.  

First, as to the kernel implementation issue.  Adding a new IKOT_* flavor
is not really hard, and having extra flavors for machine-specific features
is fine by me.  But I was also thinking it might just be easiest to stick
with device_t anyway, since it has the IPC setup all dealt with already
(and the various new bits of IKOT_* and intran/outtran magic would just
duplicate what's there for device_t).  In oskit-mach, it's easy to make a
device_t whose device_ops is all zeros and then all the IKOT/mig magic
happens but the existing device routines will all safely return error if
you ever try to send an RPC on that port.  So we could just add the new
io_port_create call and make it return a device_t that it creates with
special device_ops, and the bitmap info hung off the struct device,
and have device_t arguments to whatever the task/thread calls are.

Now, the interface issues.  What I had been thinking of was your scheme #1,
the union of of set of capabilities held by the task.  It is indeed a bit
of hair to implement holding on to the references in the task and
recomputing the union of the bitmaps after a removal, but it's not really
difficult.  However, I can't really see how to reasonably map the ioperm
interface onto that scheme.  The ioperm interface is to just turn on or off
a given range.  In scheme #1, the only way to turn off a set of ports is to
withdraw the capability you used to turn them on; so ioperm would have to
keep track of several capabilities, or have one "state of ioperm"
capability that it withdraws, destroys, and recreates differently for every
change.  Your scheme #2 makes ioperm much easier.  A root ioperm caller
could just get a capability for all ports, and then make a call saying what
change to make to the task.

I don't think extracting io port capability from the task is a good thing.
If there are RPCs for subsetting (or unioning) that can be done, they
should be sent to the io port capability port itself (like Hurd auth handles).

But again, the bottom line here is that we should not think too hard or be
too wedded to a solution right now.  We should do something that has task
scope and makes it straightforward to implement ioperm properly, and not
tell anybody to use the native interface.  When somebody is ready to
implement something that would make use of the more descriminating
features, we can work them out then.