Re: [linux-usb-devel] Re: [BK PATCH] USB changes for 2.5.34

[Larry McVoy]

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.