Messages in this thread |  | | Date | Thu, 6 Jun 1996 18:37:05 -0400 (EDT) | From | Kenneth Albanowski <> | Subject | Re: SVGA kernel chipset drivers. |
| |
On Thu, 6 Jun 1996, Jonathan H. Pickard wrote:
> 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)
|  |