cvs commit: src/sys/ddb db_command.c db_output.c

[Nate Lawson]

Robert Watson wrote:
> 
> On Mon, 3 Oct 2005, Mark Linimon wrote:
> 
>> On Mon, Oct 03, 2005 at 07:03:23PM +0200, Poul-Henning Kamp wrote:
>>
>>> There are pro etc con for both methods.  Once a dump has been sitting
>>> in a PR for a year, very few people tend to have compatible info
>>> tools available.
>>
>> The counterpoint would be that after a dump has been sitting in a PR 
>> for a year, the source base will often have drifted so much that any 
>> prior investigative work needs to be re-run.
>>
>> I'm hardly arguing against either solution here -- anything that we 
>> can do to cut out one email round-trip on e.g. the i386/kern PRs can 
>> only help us.
> 
> After the PR has been sitting there for a year or two, trying to decide 
> if it's the same bug can be quite difficult if the submitter didn't know 
> which of a dozen DDB commands to type, or know how to try to extract 
> kernel debug information using gdb.  I'm not saying this is a substitute 
> for a full dump, but that in many situations, I would get more rather 
> than less information as a result of what we're talking about.

You get the best of both worlds if you have sparse dumps and an addition 
to rc.d/savecore that does an info dump from the core to a text file.  I 
agree that the text stuff is the most useful for (auto) PR submission. 
I'd just rather go the path of saving full info and then generating an 
extract than skipping the intermediate step and generating the abstract 
directly.  That way you always have the option of going back and getting 
more info.  Sparse dumps mean that it's quick when the panic happens and 
that you can keep more around.  With multi-gigabyte RAM being common now 
but common drive speed being stuck at 7200 RPM, we're losing every day 
that we don't have sparse dumps.

-- 
Nate