| |||||||||||||
Back to the kernelBack to the kernelPosted Apr 28, 2009 10:09 UTC (Tue) by Quazatron (guest, #4368)In reply to: Back to the kernel by mikov Parent article: Packard on the state of Linux graphics
The kernel is supposed to be the bit of software that manages hardware so that applications don't have to.
It always struck me as very odd that X, being an app (a special app, but still an app) had to muck around with hardware registers, and could even bring the system down when thing went wrong.
This seems a much nicer design, with the kernel concerned with the hardware and the X concerned with drawing stuff on the screen.
(Log in to post comments)
Back to the kernel Posted Apr 28, 2009 16:37 UTC (Tue) by mikov (subscriber, #33179) [Link]
Well, the kernel being the only bit of software that manages the hardware is just dogma. You do it when it makes sense, and don't do it when it doesn't.
I am not saying that it doesn't in this case, but it is not as clear cut as people seem to thing. For one, drawing sometimes requires talking directly to the hardware. Not every graphics chip has a DMA command queue in system RAM, and even even for the ones that do, it is not always the best solution.
The command queue could be a FIFO in the chip. So, in some cases X has to talk to the hardware in order to draw. If we insist the kernel to be the only one touching the hardware, we have to make a kernel mode transition for every drawing command, which is not ideal.
|
|||||||||||||