Writing control information to a device driver is slow. ioctl's are a bit
faster, but the overhead for using them for individual port operations is
still rather flakey. Plus, the kernel _can't_ easily control any ports
above 0x3ff without some serious modification to the task tables, without
checking a table manually to find out who should get what.
> _Everything_ else would go into user-space. All the kernel does is provide
> access to the I/O ports in question and keeps more then one program from
> using them at a time.
Okay, that _might_ handle security, if you have a daemon of some sort that
sits there and monitors those port accesses. It certainly does not address
performance (made even worse by the fact that the programs now talk to a
daemon, which now lessens the burden for security on the device driver), the
ability of any schmoe to cat something evil into /dev/ioports, the need for
the graphics-using program to be setuid root (at least partially) to get
access to /dev/ioports, cards that has resources outside the "likely"
address space, or multiple VC's _at all_.
Perhaps if somehow one could put minimal support for restoring textmode into
the kernel, and pass lists of ioport accesses to ioctl (perhaps even
imparting some intelligence for waiting on bits/values or skipping/jumping,
a la the Amiga copper), it might be viable.
No need for this to be in the kernel; a simple daemon with iopl() could do
it as badly (and, with a different design, could do it better).
> --
> Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
-jhp
-- Jon Pickard * 149 Olive #45 * Paso Robles CA 93446 * +1 805 2399518 * 6372F5B9 -> I don't work for Concentric, but I don't work against them either. <- "Unix is user-friendly; it's just very particular which users it's friendly with."