Re: video mem access with oskit-mach

[Marcus Brinkmann]

On Tue, Oct 02, 2001 at 03:38:39AM -0400, Roland McGrath wrote:
> You got me.  Try it.  I think it should allow no io access, but that's what
> I would have thought about gnumach too.

No I/O access is the default as documented in the OSKit Manual.

> We need a new interface for enabling io ports, because the old CMU style
> that gnumach has is just bogus.
[...]
> 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.) 
[...]
> 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.

I have thought about it a little, and although it certainly makes sense, it
seems to be more complicated than necessary to me.  After all, you then want
the kernel to keep track of such ports, and free the associated info when it
is destroyed etc.  It seems to me that all that is needed is a way to add
and remove all or individual ioports, and then a user space server (which
you need anyway for authorization) can handle the details of the
capabilities.

What about

i386_io_port_modify (mach_port_t master_port, task_t task,
                     io_port_mod_t action, vm_offset_t addr)

where ACTION is IO_PORT_PERM_DENY_ALL, IO_PORT_PERM_ALLOW_ALL (ADDR is
ignored) or IO_PORT_PERM_DENY_ONE, IO_PORT_PERM_ALLOW_ONE and ADDR is the
port to allow/deny access to.  (You could even add another parameter if you
want to inherit the permission, this should be really simple to add).

Well, maybe it makes sense to have more than one interface for that, but you
get the idea.  It makes it possible to add capabilities in user space
without imposing any details of them on the kernel side (as to how to split
up the io ports in groups).

But maybe I am missing something about I/O ports that makes this infeasible.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de