lkml.org 
[lkml]   [2002]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-usb-devel] Re: [BK PATCH] USB changes for 2.5.34
    On Sun, Sep 15, 2002 at 03:04:35PM -0400, Daniel Jacobowitz wrote:
    > Tracking this bug down took me about six hours. Someone more familiar
    > with that particular segment of code could, I assume, have done it more
    > quickly. One advantage of a debugger is that it's easier to look at

    I'm not speaking for Linus, but I wouldn't be surprised we share the
    same view on this one. As someone who maintains a fairly large source
    base I get nervous when people tell me they need a debugger to work on
    the code. Why? Because if you really need that it is EXTREMELY likely
    that you don't understand the code. If you don't understand the code
    then YOU SHOULDN'T BE CHANGING IT. It is infuriating to have a section
    of tricky code that used to work, you turn your back, only to find that
    someone made a "simple change" which seems to work but actually makes
    things worse and invariably seems to break the code in a far more
    subtle way.

    My position is that you either understand the code or you don't. Code
    that you don't understand is read only. Having a debugger show you some
    variables isn't going to make you understand the code at the level which
    is required in order to be making changes.

    Does this mean I'm against debuggers? Not at all. But in 15 years of
    doing kernel work and 5 years of doing BK work the only thing I've ever
    used one for was to get a few variables printed out. And I've written
    a substantial chunk of a debugger years ago, it's not a question of lack
    of debugger knowledge. I just rarely find them useful.

    > Plus, in my experience the work model that BitKeeper encourages puts a
    > significant penalty on including unrelated patches in the tree while
    > you're debugging. It can be gotten around but it's exceptionally
    > awkward. Adding in KGDB means time spent merging it into my tree and
    > time spend merging it cleanly out when I'm done with it.

    Create a throwaway clone, merge in kdb, tag the tree with "baseline".
    Now hack away until you have a fix. If you never checked anything in
    after the baseline then "bk -r diffs -u" creates the patch for your
    bugfix. If you did, then diff against the baseline.

    If BK is awkward by comparison to diff and patch, something is wrong, it
    definitely has the ability to make things far more pleasant than you
    seem to be experiencing.
    --
    ---
    Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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