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

Daniel Jacobowitz
2002-09-15T23:35:56Z

On Sun, Sep 15, 2002 at 04:24:12PM -0700, Larry McVoy wrote:
> 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.

That's a circular argument. I use debuggers in order to understand
code _better_. And to understand how code that I do know interacts
with code that I don't know. I also rarely have the luxury of working in
source bases that I've got long intimate association with - about the
only code I can claim that for is GDB itself and it still surprises me.

Using a debugger I can pick up greatly improved understanding of what's
going on - both what is and what should be. And what has changed in it
recently, since I was last familiar with it, which was the problem
here.

> 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.

Good for you; as I said, everyone operates differently. The number of
printing/thinking/rebooting cycles involved for me to work with a
debugger is much shorter than without.

> > 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.

Perhaps I (yet again) need to spend a day learning more about the
depths of BitKeeper. The last time I did it all I found were BitKeeper
bugs, because the way I try to work with it appears to be contrary to
the way other people want to work with it.

I guess I just need to get more used to doing all of my development in
throwaway clones, and when it's absolutely perfect checking it into a
longer-lived tree via exporting a GNU patch and importing that.

The above model gets much more complicated when the development lasts
longer than a couple of hours, and you have to pull from another tree;
already, to upgrade my working trees I need to cascade three pulls -
with two sets of resolves if Ingo's been changing CLONE_ flags on me
again :)

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer