svn commit: r212964 - head/sys/kern

[Ken Smith]

On Thu, 2010-09-23 at 20:31 -0600, M. Warner Losh wrote:
> In message: <alpine.LNX.2.00.1009231841500.23791 at ury.york.ac.uk>
>             Gavin Atkinson <gavin at FreeBSD.org> writes:
> : 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.
> 
> Furthermore, if we aren't interested in crash dumps by default, why do
> we install the huge .symbols files?
> 
> Warner
> 

Because disks are big and (again, just trying to explain my
understanding of what I inherited) we want all the support
to be in place, just not turned on.  There is a difference
between "You can give us much better information by doing
<these extra installation steps, including installing the
.symbols goo> and then making a one-line change to rc.conf"
versus "You can give us much better information by making
a one-line change to rc.conf".

This is definitely one I don't have a strong enough opinion
on to fight over, I sympathize with both sides.  If the
general consensus is mostly towards changing so be it.
I've got no way to tell what percentage of users would
have any clue what to do with the crash info versus users
who would be negatively impacted simply by the fact their
systems are generating stuff they're completely ignorant
of and will never touch.


-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith at buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20100924/a324fc02/attachment-0001.pgp