> > Just about the only time i can think of people regularly wanting to
> > use DDB is if they _have_ to debug something 'live' on a laptop while
> > travelling (not a situation you really want to be in 8-)
> 
> But somehow, that does happen to me a lot. I suppose I should stop
> performing stunts like helping to port drivers while at IETF meetings.

I've had similar problems doing stuff like the i386 NKPDE calculation
hack and some of the APM work that i've done, at conferences.

(I'm not convinced that you couldn't do the right thing with the IR
port on the back of most laptops, but i've never actually tried it...
"somebody should."  8-)


> I also have a PC that has trouble during boot, for which DDB is the
> only tool I can use because I can't force a core dump.

If you had KGDB and a working server, then you could use it here as
well.  In general, if you're debugging something live, and have any
possibility of doing so with KGDB, you're better off doing that.


> "Better tools are better."

Yes.

My point is:

KGDB support should be considered "required" for ports to be
considered properly-functional.  DDB simply is _NOT_ good enough, and
it cannot be made significantly better than it currently is.  You can
add all sorts of tweaks and neat features, but it is inherently not
extensible via scripts and the lik, and not flexiblee.  You can add a
lot of cool one-off hacks to it (e.g. buffer traversal, etc), but if
users need any flexibility whatsoever, it loses.



cgd