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

 \ /
  Last update: 2005-03-22 13:37    [W:0.032 / U:0.824 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site