Messages in this thread |  | | From | "Jonathan H. Pickard" <> | Subject | Re: SVGA kernel chipset drivers. | Date | Thu, 6 Jun 1996 18:27:38 -0700 (PDT) |
| |
Quoth Kenneth Albanowski: > > On Thu, 6 Jun 1996, Jonathan H. Pickard wrote: > > > 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.
Ah. It does make for arbitration amongst consoles a little more interesting, but I do like the idea you've come up with below using STOP and CONT signals.
> 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.)
This means now that the VC code has to know all about suspending tasks on graphic consoles (but not necessarily on non-graphic consoles). It's also a bit harder to save other state as may be found necessary, or possibly even to let a blit finish.
> > 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.)
Well, IMHO, if we replace the video mode setting stuff we have there now with something that _just_ restores textmode on the appropriate ioctl, it wouldn't grow by more than a few K. Or perhaps we could reuse it.
> > 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.
The Amiga copper was very generic. It had three instructions: cmove (load a value into a custom chip register), cwait (wait for a certain beam position and/or wait for the blit in progress to finish), and cskip (skip an instruction if the blit has not finished or if the beam has passed a given point). There is also the cend (end of list) instruction that is really a cwait for a condition that will never happen. Quite simple, actually, and quite cleverly designed for what it had to do.
In our case, we could jack the concept up to 64-bit instructions (instead of 32-bit for the Amiga): cmove now loads either a memory location (byte, word, doubleword) in a given physical 256Mo bank or any ioport (byte, word, dw); cwait may or may not be able to wait for beam position depending on the card facilities provided, or may only be able to busywait, but can busywait for a memory location (b,w) or an ioport (b,w) logical-anded with one 16-bit quantity to equal a second 16-bit quantity; cskip has the same conditionals as cwait. If we really needed 32-bit testing we could have an extension prefix that gives the AND mask value, tells us that the next cwait is for a doubleword, and informs us that the 32-bit parameter to the next cwait is the compare value.
Problem here is that security could be almost nil in such a setup, depending on how it's done. If a root-only ioctl could set up the valid memory and port window that such a system could access, it would be a bit slower to run the list.
> > 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...
True.
-jhp (so when are named pipes going to pass ioctl's back and forth?)
> -- > Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
-- 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."
|  |