lkml.org 
[lkml]   [2000]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Availability of kdb
Linus Torvalds writes:
> On Wed, 6 Sep 2000, Alan Cox wrote:
> > When was the last time you wrote a device driver for some warped piece of PCI
> > technology that didn't work like the book says and for which you can neither
> > get more info or pop over to the next cubicle and ask the hardware designer ?
>
> That would be the CardBus controller. Yeah, still fighting that one,
> but we solved another bug today. Richard Gooch would have been able
> to use a debugger for that one, but I don't know what he could have
> done with one in that case.

Well, it would have saved me several hours of inserting printk()s and
rebooting to figure out where it was hanging. At one point I wasn't
even sure if the yenta driver was hanging, or if it was causing
another driver to hang. That would have gotten me to yenta_interrupt()
quickly. Then it could have saved me more hours (and emails to you:-)
if I could set traps and figure out what event masks were being read
and whether clearing event masks would help (i.e. is it a device quirk
or a driver bug?).

So it would have gotten me faster to the point where I (or the bastard
who wrote it:-) could sit back and think about *why* this was
happening.

I see the debugger as a tool for discarding the "obvious" ideas
quickly. If you're lucky, it is an "obvious" (read: simple) bug and
you can fix it there and then. If not, at least you've got some
confidence that you haven't overlooked something at the local level,
so it's worth investing the time thinking about the bigger picture.

Personally, in my user-space code, I use the debugger rarely (don't
need to: my code is almost perfect:-), because so often I don't need
it. Either I see the equivalent of a BUG() and think "oh yeah, that's
the foobar not frobbing the doohickey when we come in from this code
path", or I get a SEGV and I just use the debugger to find out what
function it happened in, so I know where to look and start thinking.

Very occasionally I use it to inspect variables values. You can tell
how rarely I do this by seeing how all my object code is compiled
without -g. I have to go in and deliberately recompile to get more
than a call trace.

Even less often I single-step. Less than once a year (for a one-man
part-time project of a couple of hundred thousand lines of code).

But the important thing is that the debugger is available. I don't
have to download the bloody thing. And certainly I don't have to keep
downloading it because of bit-rot. For me, it brings me faster to the
point where I sit down and think "why the fuck is it doing *that*?!?"
and look at the bigger picture.

Regards,

Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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:47    [W:0.207 / U:9.156 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site