Re: video mem access with oskit-mach

[Marcus Brinkmann]

On Wed, Oct 03, 2001 at 04:53:51PM -0400, Roland McGrath wrote:
> First, as to the kernel implementation issue.  Adding a new IKOT_* flavor
> is not really hard, and having extra flavors for machine-specific features
> is fine by me.  But I was also thinking it might just be easiest to stick
> with device_t anyway, since it has the IPC setup all dealt with already
> (and the various new bits of IKOT_* and intran/outtran magic would just
> duplicate what's there for device_t).

This sounds reasonable.  It would be a dummy device with only side effects.
However, if possible, I think it makes sense to give the RPC arguments a
name different from device_t, to avoid confusion.

> Your scheme #2 makes ioperm much easier.  A root ioperm caller
> could just get a capability for all ports, and then make a call saying what
> change to make to the task.

Sounds good to me.

> I don't think extracting io port capability from the task is a good thing.
> If there are RPCs for subsetting (or unioning) that can be done, they
> should be sent to the io port capability port itself (like Hurd auth handles).

The reason I included that is to make it possible for a security concerned
task to drop the permission, even if it doesn't have the privilege to create
a new object representing it.  I now see in Linux that they appear to allow
this (i386/kernel/ioport.c):

        if (turn_on && !capable(CAP_SYS_RAWIO))
                return -EPERM;

So if you just want to turn it off, you don't need permission.  However,
this is certainly a rare case, and we might not want to bother about it at
all now.

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