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. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
