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

Rob Landley
2002-09-16T02:31:14Z

On Sunday 15 September 2002 02:07 am, Pete Zaitcev wrote:
> > From: Daniel Phillips <phillips@arcor.de>
> > Date: Sun, 15 Sep 2002 07:10:00 +0200
> >
> >[...]
> > Let's try a different show of hands: How many users would be happier if
> > they knew that kernel developers are using modern techniques to improve
> > the quality of the kernel?
>
> I do not see how using a debugger improves a quality of the kernel.

I believe we agree that you do not see it. :)

> Good thinking and coding does improve kernel quality. Debugger
> certainly does not help if someone cannot code.

And reading glasses won't help someone who can't read. Is your above set of
statements somehow meant to imply that a debugger cannot help someone who CAN
code? (Logic. Logic is good here.)

A similar argument would be "Nobody should own an oven. If you can't cook
you'll just make a mess."

> A debugger can do some good things. Some people argue that it
> improves productivity, which I think may be true under some
> circomstances.

It's a tool. Does anybody really disagree about its nature?

The main purpose of tools is to save time. No tool is a substitute for
skill. it's possible to do everything a debugger can do via printks out to
the printer and having a stack of source code printouts, and doing all your
debugging in pencil. It's also possible to pound in a nail with a rock, if
you think hammers are for sissys.

If you stop and think about it, it's sort of like amish kernel development,
isn't it? (Hey, we've already got the community barn raising aspect. Now
let's outlaw certain construction techniques! :)

> If you work with something like Linux, and compile on something
> better than a 333MHz x86, it probably does not help your
> productivity.

I had the source code to the contractor-produce pile of cruft I worked with
under OS/2. I could even read some of it, given enough time. Trust me, a
source debugger REALLY helped find the differences between what it was
supposed to be doing and what it was actually doing. (Or more accurately,
the few places where what it was supposed to be doing and what it was doing
matched up...)

> This is all wonderful, but has nothing to do
> with the code quality.

I think we agree. So why recommend against debuggers if they save time and
effort while producing patches of equal quality?

> And to think that your users would be happier with a crap produced
> by a debugger touting Windows graduate

Sure, blame the tool. :)

> than with a quality code
> debugged with observation simply defies any reason.

So the state of the running kernel is more observablee without a kernel
debugger than with one?

Debugging means, basically, "this sucker is doing something I didn't expect
it to, and I have to find out what". A debugger is a tool with which to
examine running code. It doesn't help you write the stuff, just examine it.
The proper tool for the proper job...

The unix philosophy has always been to give people enough rope to shoot
themselves in the foot with. I'm just wondering why the exception. (Yes I
read the "bastard" speech. It seemed to boil down to a crude sturgeon's law
filter because Linus was once again being overwhelmed by crap patches (an
annual event around here). Making less than perfect coders code blind won't
increase the quality of anything, but might decrease the quanity. I suppose
that's one way of addressing the problem, but doesn't seem to me to be an
optimal solution...)

> -- Pete

Rob

(P.S. Don't mind me: I have a cold. If the above comes out as anything even
resembling english, I'm ahead of the game...)