To ensure system stability, all hardware access has to be confined to
device drivers which run in the kernel, so that they are
sanity-checked and when a process exits prematurely, it is ensured the
hardware state is not left undefined. That's the traditional reasoning
and I think it is valid even if a heap of video drivers in the kernel
would be as messy as the current heap of network drivers. ;-)
If we wouldn't follow that, we never had a parport driver in the
kernel. That one in the simplest case doesn't need interrupts or DMA
(other reasons for putting stuff in the kernel) and if you only can
access the parport I/O addresses, you can damage much less than with
access to a video card. At worst you wegde the printer[1]. BRSing a
printer is nothing compared to BRSing a computer...
Everything else belongs in user space. Really I think the proper way
to make an X server is to have a framebuffer device spiced with
acceleration ioctls[2], and let the X server use that. But that needs
some kernel support, limited mostly to mode switching and stuffing
commands into the accelerator parts. It would be messy but it wouldn't
necessary _have_ to be as messy as XFree86 is currently.
VGAs which don't support a linear framebuffer are out here (and as a
band-aid can still be used with the old XFree86 servers).
olaf
[1] My BIOS doesn't properly initialize the printer port. The printer
gets wedged by reboot until the parport driver is initialized, which
means I have to build that into the kernel. My old board worked with
that as a module. Oh well.
[2] I don't know what's going on in the video-drivers-in-kernel camp
currently, I'm just stating how _my_ model would look like.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html