[lkml]   [1998]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.


    '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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.036 / U:12.856 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site