From owner-freebsd-questions@FreeBSD.ORG Sun May 6 18:22:00 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFE1D106567F for ; Sun, 6 May 2012 18:22:00 +0000 (UTC) (envelope-from bonomi@mail.r-bonomi.com) Received: from mail.r-bonomi.com (mx-out.r-bonomi.com [204.87.227.120]) by mx1.freebsd.org (Postfix) with ESMTP id 53C998FC12 for ; Sun, 6 May 2012 18:22:00 +0000 (UTC) Received: (from bonomi@localhost) by mail.r-bonomi.com (8.14.4/rdb1) id q46IN8uu067759; Sun, 6 May 2012 13:23:08 -0500 (CDT) Date: Sun, 6 May 2012 13:23:08 -0500 (CDT) From: Robert Bonomi Message-Id: <201205061823.q46IN8uu067759@mail.r-bonomi.com> To: freebsd-questions@freebsd.org In-Reply-To: Cc: carmel_ny@hotmail.com Subject: Re: kernel configuration file X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 18:22:00 -0000 > From owner-freebsd-questions@freebsd.org Sun May 6 08:36:52 2012 > Date: Sun, 6 May 2012 09:34:12 -0400 > From: Carmel > To: FreeBSD > Subject: Re: kernel configuration file > > On Sun, 6 May 2012 08:08:31 -0500 (CDT) > Robert Bonomi articulated: > > > >If you use the "traditional" kernel-huild 'Configure/make depend/make' > >sequence, to rebuild the kernel -only-, its a matter of one minute or > >so on a _slow_ (486-class) machine. > > > >you'll either get a Configure error, a linker error, or it 'just > >works'. > > OK, now you lost me. I use the following basic sequence: > > make buildworld > make buildkernel KERNCONF=CARMEL > make installkernel KERNCONF=CARMEL > make installworld > > I am sorry, but I am not fully comprehending what commands you want me > to enter. That's the 'modern' way. Note: "make buildkernel" forcibly rebuilds everything, *EVERY* time. Including *every* loadable module, whether or not you actually use it. Which can be *really* painful on slow hardware (like 20+ *hours*, on a 486-class machine). The 'traditional' custom kernel-construction sequence is: cd /sys/{architecture}/conf $EDIT {kernelname}C config {kernelname} cd ../../compile/{kernelname} make depend make Then, 'make install', to install it as the defalt kernel to boot from, or copy it to /boot/kernel/{foo} if you just want to test it by manually selecting it at boot time.. For 'minor' kernel-only changes -- _I_ use custom kernels with =everything= I need 'compiled in', *no* loadable modules, I'm in no mood to wait for all the "never used" modules to be re-built -- The 'traditional' method is _far_ faster. On a 700 mhz PIII, it is circa 90 seconds when I make a simple configuration change -- e.g., add a 'device', change an 'option', change a 'value'. *MOST* of which is the 'make depend' stage. the actual 'make' is under 10 seconds on _that_ hardware. 'make buildkernel' always "works" for every configuration. It does it by being extremely pessimistic about what needs to be re-built. i.e., it =always= assumes everything is out-of-date. This subverts one of the major reasons 'make' exists -- to rebuild only the -minimal- set of things that are affected by a given set of changes. It is 'foolproof', but the skilled kernel builder pays an *incredible* performance penalty for using something that attemptss to outwit the classical 'sufficiently determined fool'. I don't object (well, 'much', that is, see below) to 'make buildkernel', or even to it being promoted in the Handbook as the 'preferred' means of kernel building. It _really_ annoys that it is listed therein as the -only- way. The 'traditional' methodology is fast becoming 'lost art', along with the related knowledge of _how_ the process works, 'make buildkernel' is a "black box", reminiscent of MS Windows 'magic'. When it works, all is fine. when it breaks, you've got essentially no information to work with about 'what went wrong'. With the 'traditional' method, at least all the commands have manpages, that tell you -what- each command does, in a fair amount of detail.