Date: Tue, 07 Mar 2006 15:44:37 -0600 From: Alan Amesbury <amesbury@umn.edu> To: freebsd-stable@freebsd.org Subject: Kernel INCLUDE_CONFIG_FILE workaround? Message-ID: <440DFEC5.3070501@umn.edu>
next in thread | raw e-mail | index | archive | help
In the past "options INCLUDE_CONFIG_FILE" worked great. Unfortunately,
following recent changes in how kernel configuration files are parsed
(namely the changes that use the "DEFAULTS" to include the 'isa' and
'npx' devices), this feature appears to be broken. For example, here's
what appears in an almost-stock SMP kernel (on a 6.0-RELEASE-px box):
# echo "options INCLUDE_CONFIG_FILE" >>! /sys/i386/conf/SMP
# cd /usr/src
# make KERNCONF=SMP buildkernel
.
[build magic happens]
.
# strings /usr/obj/usr/src/sys/SMP/kernel | egrep "^___"
____
____````QQQQ
___#
___# SMP -- Generic kernel configuration file for FreeBSD/i386 SMP
___# Use this for multi-processor machines
___#
___# $FreeBSD: src/sys/i386/conf/SMP,v 1.5.6.1 2005/09/18 03:37:58
scottl Exp $
___include GENERIC
___ident SMP-GENERIC
___# To make an SMP kernel, the next line is needed
___options SMP # Symmetric MultiProcessor Kernel
___options INCLUDE_CONFIG_FILE
Obviously that's not complete. There should be, at minimum, an 'npx'
and 'isa' device. ;-)
I'm not interested in rehashing earlier threads on the merits of dumbing
down or improving (depending on which side of the issue you were on)
kernel configuration through silent inclusion of devices via mechanisms
like DEFAULTS. I *am* interested seeing restored to functionality a
feature that used to work great, but is now broken.
Does anyone know if this is due to be fixed, or if there's a workaround?
(I've searched for PR's relating to "INCLUDE_CONFIG_FILE" but see
none.) One possible workaround (the one that seems to make the most
sense) is to delete DEFAULTS from /sys/`uname -m`/conf and use kernel
configs that don't use "include {otherconfig}". However, besides the
fact that DEFAULTS would come back every time /usr/src is sync'ed, I'm
unsure what the long-term ramifications are.
--
Alan Amesbury
University of Minnesota
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?440DFEC5.3070501>