> Then why splitting ioperm()'s work into two i386_io_perm_create() > and i386_io_perm_modify() calls if people should use ioperm() > rather than Mach calls? Couldn't gnumach just provide an > i386_io_perm_modify(ipc_port_t master_port, io_port_t from, > io_port_t to, boolean_t enable) call instead of the current two fancy > calls? (I'm ready to write a patch for this)
My memory on this is as dim as usual, so I am mostly making up new rationale on the spot. For one thing, I suspect I wanted to have a somewhat "Machish" interface rather than essentially an RPC veneer on an ioperm system call, on principle. More concretely, it separates the general permission from the specific permission, making the latter a transferrable capability, which is the Mach and Hurd style of doing things. Similarly, we use privileged servers like storeio to do device_open, and pass only the particular device ports to other servers in the system (at least it's possible to do it this way, i.e. have only the storeio-translated nodes be root, and have filesystems et al run without special privilege other than being allowed by storeio to get that device port). I probably had in mind then, and certainly do now, the possibility of using some privileged server to call i386_io_perm_create and pass out the specific io port capabilities according to its own authorization policies. For the ioperm interface in libc, this has to be a single central server, /dev/ioperm or suchlike. Still, that translator could implement a complicated ACL scheme for particular io ports, or at least exclusive use protection, or whatever. Native Hurdish things written to want io port access (e.g. the display and keyboard stuff), might use a different privileged translator in a more specific way. The general point being what I said above, getting the privilege to use particular io ports is a capability that has to come from the ultimate source of privilege, and applying that capability to mean something on the hardware is a separable act. Thanks, Roland _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://mail.gnu.org/mailman/listinfo/bug-hurd
