Hello! Since it's been six and a half years, let me first give some context here...
On Tue, Oct 16, 2001 at 04:16:42AM +0200, Marcus Brinkmann wrote: > here is a patch to implement I/O permission control in OSKit-Mach. > > What do you get? > ---------------- > > Two new interfaces: > > /* Request a new port IO_PERM that represents the capability to access > the I/O ports [FROM; TO] directly. MASTER_PORT is the master device port. > The function returns KERN_INVALID_ARGUMENT if TARGET_TASK is not a task, > or FROM is greater than TO. */ > routine i386_io_perm_create( > master_port : mach_port_t; > from : io_port_t; > to : io_port_t; > out io_perm : io_perm_t); > > /* Modify the I/O permissions for TARGET_TASK. If ENABLE is TRUE, the > permission to acces the I/O ports specified by IO_PERM is granted, > otherwise it is withdrawn. > The function returns KERN_INVALID_ARGUMENT if TARGET_TASK is not a valid > task or IO_PERM not a valid I/O permission port. */ > routine i386_io_perm_modify( > target_task : task_t; > io_perm : io_perm_t; > enable : boolean_t); > > The usage should be pretty obvious, an example follow below. The > capability port can be destroyed after the I/O permissions have been > modified. > > > What features are provided? > --------------------------- > > I/O permissions are task based, rather than thread based. All threads will > get permission instantly. > > The io_perm_t ports represent the capability to control the permission to > access I/O ports. A server running as root could hand out permission to > access linear port ranges for specific purposes to non-root users (like > console users to program the console). > > Applications accessing I/O ports written for GNU/Linux will be able to compile > on the Hurd without changes, as soon as glibc is extended to cover the new > interfaces (see below). > > The task switching mechanism will only use one TSS for processors. I/O > permission bit maps are edited in place. Finally, I'm now about to backport the above i/o permission interface to the gnumach-1-branch. > GNU Mach > -------- > > For GNU Mach, a kernel object would be necessary, so that a no senders > notification can be sent and the capability be destroyed. No magic, but > annoying because it would be a bit different from the OSKit Mach > implementation (nothing visible to the outside). I don't plan to "backport" > this change to GNU Mach currently, as it seems a usable OSKit Mach (with > user space console) is coming along nicely. The code in `[OSKit-Mach]/i386/i386/io_perm.c' makes use of the OSKit-Mach specific ``struct device_ops'' (from `[OSKit-Mach]/oskit/ds_oskit.h'), the ``COM object'' stuff in ``struct device'' and so on. What's the best way (or at least a feasible way) to handle that in the gnumach-1-branch? Regards, Thomas
signature.asc
Description: Digital signature
_______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
