Re: Minimal kernel support for user-space graphics drivers

Peter Horton (pdh@berserk.demon.co.uk)
Sat, 28 Mar 1998 23:25:08 +0000 (GMT)


I like the idea of whoever uses a resource informing the kernel how to
restore it. Maybe a generic (but simple, and compact) pseudo code engine
could be used for other hardware problems where the kernel/user line is
difficult to draw.

Just my two penn'eth.

P.

On Sat, 28 Mar 1998, Erik Corry wrote:

> 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
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu