Messages in this thread | | | Date | Sat, 28 Mar 1998 15:46:24 +0100 | From | Erik Corry <> | Subject | Minimal kernel support for user-space graphics drivers |
| |
Here's an idea to clean up the ragged edges in the way that current X servers handle graphics hardware without throwing the baby out with the bathwater.
The idea is to include a minimal Forth interpreter in the kernel. Before anyone screams bloat, remember that a forth byte-code interpreter can be very very small indeed, and this one can be very primitive. Essentially, all we need is inb/outb/inw/outw/inl/outl and the normal + - * dup roll if.
Now instead of poking at the card registers itself, the X server can register tiny forth programs that do the work. You register one to set the console into the right mode, and another to set it back to the base state. Obviously, both routines should be registered in one atomic system call. If the server crashes, the 'base state' proglet is executed, and when the user switches virtual consoles the same happens. The proglets must execute with interrupts off and all the data they need must in non-swappable kernel RAM.
You can even handle interrupts this way. You need a proglet to set up the task and enable interrupts, a second proglet to determine if the interrupt was for us (for PCI interrupt-sharing) and a third proglet to clear the interrupt condition. Then you make a call that registers the three proglets and blocks until the interrupt arrives.
We could make a call that gives the app proglet-priviledges that are preserved across exec. That way the X server wrapper can be setuid, but the X server need not be setuid and need not even run as root.
What this buys us:
Stable VT switching No cli/sti in user space Interrupts for X servers No root X server kill -9 xserver causes no problems Could be useful for other user-space drivers User space drivers. This is very uKernelish and trendy :-)
What we still don't have
Bugs in the graphics driver can still render the console useless There is nothing you can do about this given the reality of graphics hardware. Moving the graphics driver into the kernel would not guarantee bug-freeness. The X server could still be buffer-overflow exploited, though it would be quite difficult, since you would need to use the proglet priviledge to get anywhere. You could solve this by splitting the server up into two parts that communicate using pipes. The part with the proglet priviledge is small and simple and exploit-free. If we have a card that need large amounts of data transferred to IO ports, and we can't use DMA transfers or memory mapping then the interpreter could become a performance bottleneck. Are such cards common?
What we also need:
The ability from user space to reserve an IO port area and IRQ so that PnP devices and other drivers don't use and probe the area. This is simple.
DMA from user space. The ATM folks use this. Larry McVoy(?) suggested it be done by pinning pages down and making them sleep-on-write for the apps. This is useful for other things too, though not easy.
What do you think (apart from shut up or code up: I know)?
-- Erik Corry
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |