Messages in this thread |  | | From | "Jonathan H. Pickard" <> | Subject | Re: SVGA kernel chipset drivers. | Date | Thu, 6 Jun 1996 14:49:07 -0700 (PDT) |
| |
Quoth Kenneth Albanowski: > > On Thu, 6 Jun 1996, Systemkennung Linux wrote: > > > > > 2. Speed, lots calls to ioperm()/iopl() can't be good for > > > > performance > > > > A single call to ioperm()/iopl() isn't good for portability. > > Here's an idea: how about a _small_ kernel driver that mediates access to > the range of I/O ports likely to be used by the video card? Only one > device could open the driver at a time (that stops two processes from > grabbing the screen at the same time) and simple read/writes could read > and write to I/O ports in the specified range. (Maybe a write of 4 bytes > means output second word to the I/O port named by the first word.)
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."
|  |