kernel configuration file

Robert Bonomi bonomi at
Sun May 6 18:22:00 UTC 2012

> From owner-freebsd-questions at  Sun May  6 08:36:52 2012
> Date: Sun, 6 May 2012 09:34:12 -0400
> From: Carmel <carmel_ny at>
> To: FreeBSD <freebsd-questions at>
> 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

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.


More information about the freebsd-questions mailing list