Re: SVGA kernel chipset drivers.

Albert Cahalan (albert@ccs.neu.edu)
Wed, 5 Jun 1996 15:37:07 -0400 (EDT)

From: Ingo Molnar <mingo@kaliban.csoma.elte.hu>
> On Tue, 4 Jun 1996, eyal wrote:
>
>> I am not sure what the debate really is about. I do see the gfx
>> card as just another piece of hardware, and if a kernel driver
>> is right for one device then it is right for the other.
>
> not really. The debate is if the only code that uses gx drivers is X. We
> seem to go into that direction. (DirectDraw()). And then it's perfectly
> ok that X has direct access to the hardware.
>
> [ well, i still maintain that a kernel trap is cheaper than an IPC call,
> but if the price would be X in the kernel -> brrr. And if X would be
> still a separate process, then we had the IPC AND the kernel trap
> overhead -> this is a loss i think ]

Well, what is the kernel? Obviously the zImage, but:

Loadable modules
Process using mlock()
Kernel threads, like nfsiod and kswapd
Process using/abusing real time scheduler
Swappable kernel (someone has a patch)
Process (?) running in ring 0
IRQ handler in a process (mlocked, of course!)
Process mapped with physical addresses
Process that provides a system call
Process with contiguous memory for DMA (but perhaps not identity mapped)

You could give an X server full control over VCs, and even unload the
kernel vt102/select/VGA/scrollback/keyboard support. This moves in
the microkernel direction I believe. It would _sometimes_ help the
kernel oops problem with graphics mode. It would help speed if local
X clients could use system calls for common operations. That would
be somewhat gross, but it would be secure and fast.

The current SVGAlib/X/DOSEMU/SVGATextMode/whatever mess is not even
capable of supporting video cards that require IRQ and DMA for the
accelerator functions.