Re: [kbuild 2/5] Dont use the running kernels config file bydefault

[Andreas Gruenbacher]

On Wed, 2005-01-19 at 19:18, Roman Zippel wrote:
> Hi,
> 
> On Wed, 19 Jan 2005, Andreas Gruenbacher wrote:
> 
> > > > A user ran into the following problem: They grab a SuSE kernel-source
> > > > package that is more recent than their running kernel. The tree under
> > > > /usr/src/linux is unconfigured by default; there is no .config. User
> > > > does a ``make menuconfig'', which gets its default values from
> > > > /boot/config-$(uname -r). User tries to build the kernel, which doesn't
> > > > work.
> > > 
> > > NAK. This isn't normally supposed to happen and it shouldn't be as bad 
> > > anymore as it used to be. Removing these path doesn't magically create a 
> > > working kernel.
> > 
> > "Not normally supposed to happen" and "shouldn't be as bad anymore"
> > aren't very sound arguments.
> 
> It's as precise as above problem report. 
>
> > It's fundamentally broken to use a
> > semi-random configuration for a kernel source tree that may be
> > arbitrarily far apart.
> 
> No, it's not. Please provide more information why exactly this is broken.

Okay, more verbose then. On your machine which is running kernel version
x you build kernel version y. You grab the version y kernel source tree,
let's say a vendor tree, which has meaningful default configurations in
arch/$ARCH/defconfig. The runnig kernel's configuration may also work
for that kernel source tree, or it may not.

The user does a ``make menuconfig'', and expects to see sane defaults.
What kconfig really does is take the running kernel's configuration
instead. This is a ad choice; it makes much more sense to take
arch/$ARCH/defconfig.

> > It's not uncommon that users who build their own kernel modules often
> > are very clueless. Nevertheless we shouldn't cause them pain
> > unnecessarily.
> 
> So they should first try the 2.6 kernel provided by the distribution and 
> then try compiling their own kernel. In this situation it's actually more 
> likely that they produce a working kernel with the current behaviour, the 
> defconfig is not a guarantee for a working kernel either.

You assume that the user is already running the kind of kernel he is
trying to produce. Al least to me this assumption seems weird. Instead
my proposal is to use a different make target if you actually do want to
clone the running kernel's configuration, but this shouldn't be the
default.

> Sorry, but as long as nobody writes an autoconfig tool for the kernel, the 
> kernel configuration is not a simple process and any default can only be a 
> compromise and may fail. If you have evidence that there are better 
> defaults, we can change this, but your problem report above is not enough.

I'm not trying to add more magic, I'm trying to get magic taken out,
because nothing guarantees that taking the running kernel's
configuration makes sense. The kernel packages we ship have meaningful
default configurations on all architectures that allow this. You won't
end up with a highly optimized configuration for your particular
machine, but nothing guarantees that you will end up in a better state
with the running kernel's config.

Cheers,
-- 
Andreas Gruenbacher <agruen@xxxxxxx>
SUSE Labs, SUSE LINUX GMBH

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/