[lkml]   [1996]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SVGA kernel chipset drivers.
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...


(so when are named pipes going to pass ioctl's back and forth?)

> --
> Kenneth Albanowski (, 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

 \ /
  Last update: 2005-03-22 13:37    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean