From owner-freebsd-stable@FreeBSD.ORG Fri Nov 4 09:36:55 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36F2016A421 for ; Fri, 4 Nov 2005 09:36:55 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A407943D48 for ; Fri, 4 Nov 2005 09:36:54 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3495646B98; Fri, 4 Nov 2005 04:36:54 -0500 (EST) Date: Fri, 4 Nov 2005 09:36:54 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Brett Glass In-Reply-To: <200511040039.RAA21926@lariat.net> Message-ID: <20051104093232.I9692@fledge.watson.org> References: <200511040039.RAA21926@lariat.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@freebsd.org Subject: Re: Nogobble, nogobble X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2005 09:36:55 -0000 On Thu, 3 Nov 2005, Brett Glass wrote: > The notion of creating directives to reverse those in a file of defaults > (the most amusing one being "nocpu", which sounds as if one is saying > that the system has no CPU) shows how absurd this approach is. Yes, it's > handy to have defaults; however, if one is building a custom kernel at > all one is most likely building something vastly different from the > original or it would not be worth doing at all. He or she and should > expect to specify in detail what will be included in it. Copying GENERIC > (or LINT, which is now absent but used to be extremely handy) and then > editing it is a far better and less error-prone way of crafting a kernel > than having to inspect a file and then hopping back and forth to another > editor window disabling EVERYTHING in the first file you don't want > (which can be quite a list if you're trimming down the statically linked > portions of the kernel to the hardware that your machine actually has). In practice, I've found the include mechanism extremely valuable in keeping a number of variations on a single kernel synchronized. For example, when configuring systems, I often have a UP configuration, an SMP configuration, sometimes a couple of specific extension kernels, and a full debugging version of each. While the current mechanism still allows me to do it the old way, that approach is prone to error: what I want is a single base configuration (be it GENERIC or RWATSON or whatever), and then a series of variations that I can easily maintain. If you prefer to copy GENERIC, no one is stopping you, but I find the copy-and-paste approach quite error prone in practice, especially when tracking a branch, as it requires manual propagation of changes to all the kernel configurations. BTW, LINT does exist, but it is generated dynamically using "make LINT" in the configuration directory. This combines both cross-architecture and architecture-specific NOTES entries to produce a kernel configuration. Robert N M Watson