lkml.org 
[lkml]   [1998]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectMinimal 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

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