svn commit: r212964 - head/sys/kern
Gavin Atkinson
gavin at FreeBSD.org
Thu Sep 23 18:00:03 UTC 2010
On Thu, 23 Sep 2010, Ken Smith wrote:
> The issues talked about so far all contribute to the reason for that.
> But one of the more basic gut reactions to it all is that the users
> want to be interested in helping with the debugging (even if just
> providing the requested info) for any sort of crash information
> to be useful. And at the point we shift something from -current
> to -stable the percentage of people actively interested in participating
> in that sort of stuff flip. The bulk of people using -current
> know it's risky and they do it out of some interest in debugging
> stuff. The *bulk* of people using -stable are less interested or
> flat out not interested. And have no clue what crash dumps are,
> may be challenged to notice partition-getting-full issues, etc.
I'm not sure I buy this argument, I'm afraid. Part of the advantage of
having all this done automatically on the as-shipped release media is that
end users don't have to be interested in debugging - crashinfo(8) does
most of the work for them. There's no easy way to actually determine
figures, but even if say only 10-15% of crashes can be diagnosed and
corrected just from the output of crashinfo(8) then that's a huge win for
the project as a whole. I'm guessing 10-15% is not unrealistic.
I appreciate the issue about filling partitions is a valid one. Would a
possible compromise be that on release media, crashinfo(8) or similar will
default to only keeping the most recent coredump or similar? Given /var
now defaults to 4GB, Defaulting to keeping a single core is probably
acceptable.
Gavin
More information about the svn-src-head
mailing list