Linus Torvalds wrote:
>
> 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.
Yes, no doubt you agree that stepping through the code with a source
level debugger even once would have caught this one:
>
>> Code; c012cae6 <block_truncate_page+d2/1c8> <=====
>> 0: 8b 00 movl (%eax),%eax <=====
>
>Offset 0 is ->b_next... Huh? It should be ->b_this_page, no?
>
But that fits with your argument that debugging the kernel should not
be easy, so there is no inconsistency. As long as having the kernel
progress quickly doesn't matter to you, there's no inconsistency there
either. It progresses fast enough for me. Right now, I'm debugging
exactly the way you like to, and by coincidence, exactly the same
code. If I wanted to, I could install sgi's kdb patch and do this
more efficiently, but what the heck. Maybe tomorrow. I'm more than
adequately entertained. I'm fortunate to be in the position where
rapid forward progress just doesn't affect my paycheck. I can think
about the things I like to think about, work on the problems that
interest me.
I have a dream job. Others are not so fortunate.
-- Daniel - 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/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:27 EST