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."