lkml.org 
[lkml]   [1998]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kill -9 <pid of X>
On Thu, 13 Aug 1998, Olaf Titz wrote:

> > Before anybody starts trying to convince me that there is kernel help
> > needed, they'd better have their facts straight.
>
> 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. ;-)

Right. Mess, hassle, ease of use, ease of coding, etc are NOT the
most important thing system stability is the most important thing. You
can choose to discard some or all of that stability for speed if you want,
but the stability option MUST MUST MUST be there if needed!

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

It is a better idea to write the X server on top of a portable
usersapce graphics library, so you aren't tied so closely to Linux and so
you don't have to code support for fifty billion card-specific ioctls into
your X server. That is what XGGI does - it rides on top of LibGGI, and as
such I can retarget the X display to any display target LibGGI supports.

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

There is no way in hell it could be anywhere close to as messy and
XFree86. Take a look at some KGI driver source sometime if you are bored.
It is surprisingly clean and understandable.

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

Or the driver can use mmap() to create a pseudo-linear framebuffer
out of the banks. KGI does this.

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

You'd get a little more speed out of having the X server sit right
on top of the kernel and feed ioctls to /dev/fb, but the portability loss
wouldn't (IMHO) be worth it.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed


-
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

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