> 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.
OK, then that won't work.
> 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_.
I think you missed one think: the driver itself would perform locking.
Only one task could open "/dev/ioports" (or whatever) at a time. No
deamons, and no schmoes allowed, assuming that something has already
grabbed the driver.
As for cards with resources outside the "likely" address space: obviously
this can't be guessed. So a program would have to open up /dev/ioports,
play around with the card enough to figure out what resources are needed,
and then tell the driver to allocate those resouces.
As for multiple VC's, I don't think this would be a problem. Two programs
cannot control the video card simulatenously. So to perform a cross-task
VC switch, the first task would close /dev/ioports when it gets told to
background itself, and the second task opens up /dev/ioports when it wakes
up. (This doesn't deal with allocating VRAM in a useful manner to save on
(or _for_!) swapping. That's only possible if the kernel knows all about
VRAM.)
> Perhaps if somehow one could put minimal support for restoring textmode into
> the kernel,
This is currently needed, but I don't see how it's feasible. And it
certainly wouldn't be portable. There are too many video cards with too
many weird registers to support some method of restoring textmode. (That's
one of those fundamental problems with the current VGA architecture.)
> 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.
What I'm wondering is whether a very generic driver could be designed
along these lines.
> 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).
Indeed, since this mini-video-driver approach wouldn't help the kernel
shift back into textmode (and perform similar tricks) there isn't any need
to have a kernel driver in the first place...
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)