From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 17:29:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 094D416A4CE; Wed, 20 Oct 2004 17:29:02 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B603843D31; Wed, 20 Oct 2004 17:29:01 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i9KHTt9Y031721; Wed, 20 Oct 2004 10:29:55 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i9KHTtRm031720; Wed, 20 Oct 2004 10:29:55 -0700 Date: Wed, 20 Oct 2004 10:29:55 -0700 From: Brooks Davis To: Maxim Sobolev Message-ID: <20041020172955.GG11477@odin.ac.hmc.edu> References: <41767CF1.2020005@FreeBSD.org> <20041020165900.GB834@alex.lan> <41769E70.4020808@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41769E70.4020808@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: arch@freebsd.org cc: "current@freebsd.org" Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 17:29:02 -0000 On Wed, Oct 20, 2004 at 08:20:48PM +0300, Maxim Sobolev wrote: > Let me clarify it down: it is only applies to HEAD, that is, unstable > branch, which can be inheretedly buggy. STABLE/RELEASE doesn't really > need this feature. This dismisses the following objections: I think it's more important in HEAD, but personally I would like to ship this way. It has the potential to vastly improve the quality of bug reports. That's not my call though. > 1. HDD size constrains: nobody really want to run unpatched HEAD on CF > or the like, since with HEAD you are expected to re-compile more than often. > > 2. / partition size: anybody running HEAD is expected to allow this > accomodate debugging kernel. > > 3. Additional slowdown: since it is adds up to 10 seconds (I bet that > even less on a modern system) who cares? This is HEAD, so that it is > expected to be sub-optimal performance-wise. I seriously doubt it's measurable. If it is, the loader is broken. :-) We're talking about reading a section header and doing a seek for each ELF section we don't care about (all the ones that bloat the file relative to the stripped version.) -- Brooks