[lkml]   [2000]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: The case for a standard kernel debugger
On Wed, 13 Sep 2000, Timur Tabi wrote:

> ** Reply to message from Keith Owens <> on Thu, 14 Sep 2000
> 08:49:50 +1100
> > (5) Easier for kernel beginners to learn the kernel internals. Having
> > worked on 10+ operating systems over the years, I can testify that
> > some form of kernel/OS tracing facility is extremely useful to get
> > people started.
> Excellent post, but I can relate to this point the most. Using the debugger to
> aid in understanding the kernel is akin, IMHO, to knowing assembly language
> when programming in a high-level language. People who understand how the
> computer works (which is only possible if you know asm) are better programmers
> than those who don't. Similarly, interacting with the kernel while its doing
> its "magic" makes it easier to understand that magic.
> I lost a lot of respect for Linus when he made comments that basically implied
> that I was not worthy of learning the Linux kernel because I did not want to do
> it the hard way.

So Linus is right. His main argument is about people selection. Keep
the ones who don't want to do it the hard way out of the door.
You're just saying that his strategy is succeeding.

Let me ask: if you want to learn how the kernel works, and you think you
need a debugger, why don't you apply the patches yourself? What Linus does
with his own tree has little impact on you. You won't buy Linus with the
'learning' argument, I think.

I don't think Linus' main point is "do I the hard way or don't". The point
is that "doing it with a debugger is not the easy way". It seems to be
easier but you don't get the Knowledge. So in the end it's 'the right way'
vs. 'the wrong way'. not 'hard' vs. 'easy'. In this, I must say I agree
with him. I'd also add that source code is (should be) a language to
express ideas (at the same time to implement them). With a well written
source, you don't need a debugger at all to understand 'how it works'.
And if you find you need it, we've quite a problem with the source
in the beginning. Source code should be more human readable than debugger
output, *expecially* for beginners. In this Linus is doing a great job.

My points againts Linus' arguments:

1) you should give people freedom to do what they do. If they want to spend
thier time with a debugger let them do. This 'social engineering' thing
is crap. You don't make people better by filtering them.

2) apply tight filters on what people produce (patches, features) not on
how they produce. If Linus is right (and in the end I believe it),
'debugger people' will produce low quality patches (the ones that fix
the syntoms not the problems), and those patches won't be blessed
by Linus. I think Alan made the point that those patches sometimes
may be useful to others who are looking for the real problems.

Also, Jeff, if you're reading this, go on with your (better) debugger.
The whole point of releasing something under GPL is the feedback you
get for free, which sometimes happens to be high quality feedback,
contributions, bug-fixes, an so on. You get a better product, in the end,
and since you find it useful to you, in primis, it makes *your* life

____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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