lkml.org 
[lkml]   [2000]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
    Date
    From: "Horst von Brand" <vonbrand@inf.utfsm.cl>
    > 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...

    So you place your money into the bank until you have a "large enough sum
    to be worth investing in a mutual fund or stock", I presume. If not then you
    SHOULD understand the invest now for returns later ideas. If the time is
    invested now the return on investment later will be far greater than if they
    finally grudgingly try to do it later.

    While I was at Magnavox I watched several software projects from
    proposal through production code. The more time that was invested
    up front in tools the more likely the project was to be on time and on
    budget or even under budget. (And this was with that roundly dispised
    thing called Ada. Go figure.)

    I rather strongly think it is well past time to make the debugger
    investment. But building a good one is hard to do. Where is someone
    smart enough and capable enough to get the core built so that there
    is a rational debugger project to parallel the kernel development?
    It's not a glamorous job. But somebody ought to grit their teeth and
    get their name on The Linux Kernel Debugger. I suspect the community
    would remember THAT person a LONG time. I kinda wish I had the
    time and that it better fit my skill sets. I know the people who fit the
    project are out there earning REALLY big bucks from Raytheon
    and Rockwell as well as some of the more often thought of companies.

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

    "If it was hard to design by God it should be hard to maintain, too."

    > 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, I think you are pointing out one of the more
    splendidly large worms in the Open Source apple. Better tools are
    needed and if they exist they would be used. But nobody wants the
    job. So it doesn't get done.

    Alas, *I* do not have a solution other than maybe to embarrass someone
    into doing what has to be done and geting intense satisfaction about that
    when it is done.

    {^_^}



    -
    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:41    [W:7.311 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site