Re: Gnumach and I/O

[Roland McGrath]

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