Messages in this thread |  | | Date | Mon, 3 Jun 1996 08:53:51 -0400 (EDT) | From | Ingo Molnar <> | Subject | Re: SVGA kernel chipset drivers. |
| |
On Sun, 2 Jun 1996, Jon M. Taylor wrote:
> Which is why the SVGAserver idea is broken. We need individual > device drivers for individual graphics cards for the same reason that we > need individaul drivers for different sound cards - because each card does > different things and does the same things differently. It is too > dangerous and kludgey to allow userspace programs to have THAT much > control over the hardware.
well, it's not broken.
i see no conceptual difference between a trusted binary (and *only* the trusted binary should access the IO ports), and a kernel device driver.
The problem is that some graphics activities cant take the IPC performance hit. [but the overhead of a kernel trap would be worth it]. It's true that most graphics activities deal with the framebuffer (or something alike it), so this point has to be considered carefully.
Imagine, to do a palette change, we would have to switch to another process and back. Or to do a hard scroll.
Another problem might be that you can't cli() from userspace. And if someone ever gets IRQ9 going, then we need kernel support for that at least. (and we want then to protect our code from IRQ9, which in turn needs cli() ...)
but anyways, as Alan has said, get the code working and prove your concept. This aint no ego-trip OS, experience is that if your code is right, then it has fair chances to get into Linux :)
-- mingo
|  |