bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: video mem access with oskit-mach


From: Roland McGrath
Subject: Re: video mem access with oskit-mach
Date: Tue, 2 Oct 2001 15:54:46 -0400 (EDT)

> 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.

But that's already implemented!  The existing iopb code works exactly this
way.  All we have to change is its use of device_t to use a generic
ipc_port pointer instead.

> 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.

That would work, but it seems more clunky than the kernel-supported
capability interface.  I can't off hand tell you quite why, but it just
feels more Hurdish to get a capability and use that to tell the kernel to
frob your own task, than to hand some server you task port and tell it to
frob you.

Yeah, that's why.  You don't hand anybody your task port if you can help
it.  proc has to have it, but nobody else does.  The server in charge of
the io ports doesn't even need to be able to get your task port really,
because it could have the device master port but not the host-priv port or
the root uid.  

The more nebulous reasons are that you might get this capability,
hang on to it for later, pass it to other tasks, etc.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]