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