From owner-svn-src-all@FreeBSD.ORG Fri Sep 24 02:35:47 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D774106564A for ; Fri, 24 Sep 2010 02:35:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2B1528FC18 for ; Fri, 24 Sep 2010 02:35:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o8O2VYgZ024003; Thu, 23 Sep 2010 20:31:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 23 Sep 2010 20:31:43 -0600 (MDT) Message-Id: <20100923.203143.19192035494300157.imp@bsdimp.com> To: gavin@FreeBSD.org From: "M. Warner Losh" In-Reply-To: References: <20100922222441.00002f27@unknown> <1285253887.95760.33.camel@bauer.cse.buffalo.edu> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: bruce@cran.org.uk, src-committers@FreeBSD.org, jhb@FreeBSD.org, kensmith@buffalo.edu, svn-src-all@FreeBSD.org, avg@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r212964 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 02:35:47 -0000 In message: Gavin Atkinson 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