Messages in this thread |  | | From | Albert Cahalan <> | Subject | Re: SVGA kernel chipset drivers. | Date | 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.
|  |