Re: svgalib I/O permission

[Roland McGrath <frob@debian.org>]

> It looks like a process wanting to access video I/O ports should
> first open the "kd" device, and then GNUmach would give it access
> to the ports listed in i386/i386at/kd.c (vga_port_list) the first
> time it tries to use them.  Is this right?

I'm not entirely sure.  (I'm just going from reading the kernel source
here, same as you.)  From what I can see, that is not quite right.
The situation with getting io port access is somewhat baroque.

It looks like the cleanest thing available is to use the RPCs in
<mach/mach_i386.defs>.  (Unfortunately it looks like I didn't include those
stubs in libc's standard RPC library, libmachuser.  We will try to remedy
that soon; it may be a little sticky.  In the meantime you can add
mach/i386/mach_i386.defs to the user-interfaces list if you are building
your own libc--just don't distribute the resulting libmachuser.so to anyone
until we figure out the binary compatibility issues.  Or, you can just
build your own client stubs using mig.)

The way that works is that for each thread that wants to get io access, you
do an `i386_io_port_add' RPC on that thread's control port with the Mach
device port of the device whose io ports you want to use.  So, for a
single-threaded program like svgalib probably is, just do:

	err = i386_io_port_add (mach_thread_self (), kd_device);

where `kd_device' is a mach port you got from `device_open' on "kd".


There is an additional kludge available to get io ports, in the Mach "iopl"
device.  It appears that if you have a send right for that device port in
your task, then you get access to a bunch of io ports (iopl_port_list in
i386/i386at/iopl.c).  This seems like a stupid kludge, but it does have the
feature of automatically setting up io permissions for each thread when it
first attempts to use it.