lkml.org 
[lkml]   [2000]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
    Date
    From
    "J. Dow" <jdow@earthlink.net> said:

    [...]

    > I note again that the same arguement applies vis a vis printk
    > and desk checks with a paper and pencil. The printk leverages
    > the capable person's time. The kernel debugger leverages
    > the capable person's time. What IS this urge to be handicapped
    > when trying to debug the most important pieces of what gets
    > delivered on the distribution CDROMs.

    Problem is:

    - Debugging code has to be written, integrated and debugged. It has to be
    designed for collecting certain types of data. If you get the data to be
    collected wrong, it is useless (and as you don't know what bugs you are
    looking for, you _will_ get it wrong most of the time, unless you collect
    everything in sight)
    - Debugging code impacts readability, writeability, and performance of the
    instrumented code, specially if it is pervasive (and most functionality
    isn't localized)
    - Debugging harnesses have to evolve together with the instrumented
    code. If they don't, they are just a liability. If they do, they double
    (probably more) the development time, as they have to be kept in synch.
    - Broken debugging code impacts stability

    Do we want Linus & Co. writing cool kernel code or writing a whiz-bang
    kernel code debugger? Developer time _is_ finite, you know...

    Witness the people who have argued _against_ integrating debugging code
    into the kernel, *even code they designed and wrote themselves*.

    Check out stuff like the user-level kernel, AFAIU there it is possible to
    attach a run-of-the-mill debugger to a live kernel. Or look at the remote
    debugging stubs for gdb.

    It is not that they don't want better tools, the problem is that the tools
    available (or buildable at a reasonable cost) are woefully inadequate to
    the task at hand. Typical (low-level!) question when debugging is "Where
    the $EXPLETIVE does this $WRONG_VALUE in $RANDOM_VARIABLE come from?", and
    no current debugger is able to give you even that little. Sure, you can
    single-step to the point of failure, but it is often faster to just grep
    for the places where it can be changed. Don't even think about asking stuff
    like "Why is $RANDOM_FUNCTION being called so much?". Given this scenario,
    the only useful tool is a good understanding of the kernel; instrumentation
    which gets more in the way than its usefulness warrants is just left out,
    or rots away.
    --
    Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
    Departamento de Informatica Fono: +56 32 654431
    Universidad Tecnica Federico Santa Maria +56 32 654239
    Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:39    [W:0.021 / U:30.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site