lkml.org 
[lkml]   [2000]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Availability of kdb
torvalds@transmeta.com (Linus Torvalds)  wrote on 06.09.00 in <Pine.LNX.4.10.10009061232440.1044-100000@penguin.transmeta.com>:

> On Wed, 6 Sep 2000, Tigran Aivazian wrote:
> >
> > very nice monologue, thanks. It would be great to know Linus' opinion. I
> > mean, I knew Linus' opinion of some years' ago but perhaps it changed? He
> > is a living being and not some set of rules written in stone so perhaps
> > current stability/highquality of kdb suggests to Linus that it may be
> > (just maybe) acceptable into official tree?
>
> I don't like debuggers. Never have, probably never will. I use gdb all the
> time, but I tend to use it not as a debugger, but as a disassembler on
> steroids that you can program.
>
> None of the arguments for a kernel debugger has touched me in the least.
> And trust me, over the years I've heard quite a lot of them. In the end,
> they tend to boil down to basically:
>
> - it would be so much easier to do development, and we'd be able to add
> new things faster.

That's never been my argument. My argument has always been "it's far
easier to *understand* tough bugs with a debugger".

BTDTGTTS. *Easy* bugs don't *need* a debugger to fix.

Tough bug: a place where reality doesn't match your understanding.

In which case, you often need to go exploring. Which is roughly 100 times
as fast with a debugger compared to, say, printk. (Think about it. You get
a new idea what to look at, you insert a new printk, you recompile, you
reboot, you re-trigger the bug. Whereas if you're running a debugger, you
just examine a different piece of memory.)

Often you look at various different places before you finally locate the
one that's giving you the missing clue.

> And quite frankly, I don't care. I don't think kernel development should
> be "easy". I do not condone single-stepping through code to find the bug.
> I do not think that extra visibility into the system is necessarily a good
> thing.

Well, it's pretty certainly never a *bad* thing.

> To me, it's not a bug, it's a feature. Not only is it documented, but it's
> _good_, so it obviously cannot be a bug.

Sorry, you haven't shown it's good either. All the claims about it weeding
out poor techniques I've seen lacked any serious support.

There's one thing that can make for debugger abuse (but in fact can abuse
any other debugging technique just as well): management pressure.

But "management pressure" does not seem to apply to Linux kernel
development in any meaningful way. Everybody wo looks even remotely like a
Linux kernel development manager (such as the Messiers Torvalds, Cox,
Miller, and so on) already understands about good and bad bugfixes, and
how "we must get this out to the customer or lose $$$" is a bad argument.

> My biggest job is to say
> "no" to new features, not trying to find them.

So, if someone with a debugger creates a bad patch, nobody is forcing you
to accept that patch.

> Oh. And sure, when things crash and you fsck and you didn't even get a
> clue about what went wrong, you get frustrated. Tough. There are two kinds
> of reactions to that: you start being careful, or you start whining about
> a kernel debugger.

I don't even see that a debugger makes all that much difference in *that*
scenario. When you have a bug that corrupts the fs, how is a debugger
magically going to remove that corruption?!

What it can do is make you understand what's going on faster. And that
*is* a good thing. Always.

> Quite frankly, I'd rather weed out the people who don't start being
> careful early rather than late. That sounds callous, and by God, it _is_
> callous. But it's not the kind of "if you can't stand the heat, get out
> the the kitchen" kind of remark that some people take it for. No, it's
> something much more deeper: I'd rather not work with people who aren't
> careful. It's darwinism in software development.

Except that "careful" doesn't seem even remotely relevant to the question.
I certainly don't see how a debugger lets you be less careful.

> I'm a bastard. I have absolutely no clue why people can ever think
> otherwise. Yet they do. People think I'm a nice guy, and the fact is that
> I'm a scheming, conniving bastard who doesn't care for any hurt feelings
> or lost hours of work if it just results in what I consider to be a better
> system.

But it doesn't. I'm pretty convinced that in this point, you're entirely
barking up the wrong tree.

> I happen to believe that not having a kernel debugger forces people to
> think about their problem on a different level than with a debugger. I

I happen to believe that this is just plain wrong.

> think that without a debugger, you don't get into that mindset where you
> know how it behaves, and then you fix it from there. Without a debugger,
> you tend to think about problems another way. You want to understand
> things on a different _level_.

Maybe you do - I certainly don't.

In fact, it's often been exactly the other way around for me. With a
working debugger, I can understand exactly what's happening, and can write
a fix I'm confident solves that problem.

Without a working debugger, I'm reduced to guessing, and often I cannot
really check on my guesses, so I make "fixes" based on those guesses - and
the quotes are there for a reason.

"This ought to work, but it crashes. There's no good reason why it crashes
that I can see, it just does. And the debugger in this case won't show me
even a traceback from the crash. So let's just put in a different, slower
solution, that we hope won't crash - see, it really doesn't."

I recently had that, and I can assure you it doesn't give me warm fuzzies.
Groping around in the dark is a *horrible* debugging technique. And this
is *exactly* the situation where a working debugger makes all the
difference.

> It's partly "source vs binary", but it's more than that.

It is, except I believe you have the sides confused. The binary side is
the no debugger one.

>It's not that you
> have to look at the sources (of course you have to - and any good debugger
> will make that _easy_). It's that you have to look at the level _above_
> sources. At the meaning of things. Without a debugger, you basically have
> to go the next step: understand what the program does. Not just that
> particular line.

And with a debugger, you *still* have to do exactly that. It's just
easier.

> And quite frankly, for most of the real problems (as opposed to the stupid
> bugs - of which there are many, as the latest crap with "truncate()" has
> shown us) a debugger doesn't much help. And the real problems are what I
> worry about. The rest is just details. It will get fixed eventually.

There are two kinds of bugs: easy to fix, and hard to fix.

We can ignore the easy ones here, they don't need help.

There are two kinds of hard to fix bugs: those where you understand what
went wrong and can't think of a fix, and those where you don't understand
what went wrong.

We can ignore the ones here which you already understand, because a
debugger won't do anything for you there.

What's left desperately needs a debugger.

> Because I'm a bastard, and proud of it!

I notice people often are proud of being wrong.


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