In the real world, any user of an io port capability is going to know exactly what ports it's good for, because it has to actually use the ports. Your example does not seem too likely to me.
Anyway, I'm not saying the interface I wrote is necessarily wonderul. glibc already uses it for ioperm, but if that is not actually used in practice by anything, then it won't hurt to make it use something different. The essential principle to keep in mind is that the microkernel should do as little as possible. The interface I wrote fairly well approximates that, while making it possible to do something with capabilities that avoids giving out your task port to any other agents, which is the way we have always done things in the Hurd to the extent possible. It does seem reasonable that you should always be able to disable ports without having any speical capability on hand, and I do recognize the issue you cited with using some capability supplied by somebody to disable a range of io ports when you technically cannot be sure what the range is. Those concerns would be served by i386_io_perm_modify taking the from, to arguments as well as the enable flag; it would require a capability whose range includes the requests ports to enable, but not care for disable. (I guess this could as well be two separate RPCs for enable/disable.) I don't buy the idea that a user won't know what io ports he needs enabled. If you're using ioperm, you meant disable what you said. If you are using some fancy Hurdish driver module like what you might (one day) get via libstore, libchannel, console-client, etc, where two related devices should get access to overlapping io ports on open and dtrt when one is closed, then you can damn well be using some fancy Hurdish library to manage your io port access for you. Thanks, Roland _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://mail.gnu.org/mailman/listinfo/bug-hurd
