Re: video mem access with oskit-mach

[Marcus Brinkmann]

On Tue, Oct 02, 2001 at 03:54:46PM -0400, Roland McGrath wrote:
> > 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.

Sorry, I am writing way too much on this, but I have spent a fair amount of
time digging in the code and complications pop up everywhere.  I don't think
it is as simple as you say, but then I haven't settled on the interface
either.

One basic question is how adding and removing should work.  One strategy is
that you would assign io_port objects to tasks, and that it would keep track
of which io_ports are assigned to a certain task.  The union of all these
objects would specify the permissions you have, and i386_io_port_list
returns ports to he io_port objects.  This is close to what iopb does with
device ports.  Reference counts would make sure io_ports don't die even if
you destroy the send rights, but you have to make sure you release the
references when the task is destroyed.

The other strategy would be to just keep a bitmask for every task requiring
I/O permissions, and modify that bit mask with each add or remove operation.
The io_port objects would only be used to specify which io ports to permit
or forbid.  The _list operation would return a list of io ports that are
permitted, and a _create operation succeeds for any port set if the device
master port is supplied and for a subset of the permitted io ports for a
task if the task port is supplied.

Well, I am not 100% happy about either solution, but that's the best I can
up with right now.

Another issue that is different from the current iopb code (beside the
thread/task based-ness) is the need for no-sender notifications, which
requries the object to be registered as kernel object... and that will force
more machine dependant code in kern/ipc_object.c.  yuck.

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