lkml.org 
[lkml]   [1998]   [Aug]   [12]   [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, Alan Cox wrote:

> > On Wed, 12 Aug 1998, Jon M. Taylor wrote:
> > > Yes, but the difference if the kernel video drivers crash, I know
> > > where to start looking. If X crashes and screws up the video card, the
> > > video drivers *could* be the problem. But a whole lot of other things in
> > > the X server could also be the problem. XFree86 4.0, which has separate
> > > video driver libraries, should help clear this problem up a lot though.
> >
> > The kernel is bigger than X, and harder to debug, too. Have you read
> > Unix for Dummies yet?
>
> The X server is a lot harder to debug than the kernel. Its large, it takes
> ages to build and video hardware was mostly designed by people who evidently
> then didnt have to program it.

Here's even yet still more reasons why the X server is harder to
debug video drivers in than the kernel:

* It uses those horrible Imakefiles. Blech! |->
* The commenting is inadequate, to put it mildly.

* The guts are "designed" to optimize X efficiency. As a result, the
internal interfaces are messy, unintuitive and often ad hoc. Tracing the
flow of execution through XFree86 is a nightmare. I know, I've had to do
it many times.

* The video drivers are monolithic and a spaghetti-like mess of #if blocks
and special cases, spead out over large numbers of poorly-organized source
files. It is as bad as the worst BASIC code I have ever seen.

* The poking of the hardware is sprinkled all through the modesetting
code, which means that there are largeish chunks of code which can't be
stepped through reliably.

* A lot of hardcoded hex values are used all over the place. Every
freakin' time you see a hardware poke, you have to pull out your hardware
references to figure out what the hell they are doing.

* Register states are saved on a completely ad hoc basis. It is hard as
hell to figure out what registers are being saved, for how long, if the
order is important, etc.

I only crack open the XFree86 sources when I have exhausted all
other alternatives. The code just screams "maintained by one person for
years". The KGI drivers are so many light-years ahead in terms of
modularity, consistency, readability and commenting that it isn't funny.
The KGI drivers have their own problem areas, but overall I'd rather debug
a KGI driver for the most ill-behaved hardware than an XFree86 driver for
the best hardware in the world. It's that bad.

There's no way code that crufty would last long in the kernel -
either the coders would get yelled at by Linus or outside coders would
take it upon themselves to clean up some of the mess. Stuff like that
doesn't get to absurd extremes in a truly open development system. In the
cloistered ivory tower of XFree86 development, it just keeps going and
going and going.... XFree86 4.0 will supposedly clean some of this mess
up. We'll see.
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    [from the cache]
©2003-2011 Jasper Spaans