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.
I would like to get rid of using the running kernel's configuration
unless the user explicitly requests it. Instead, please add the
cloneconfig target to clone the running kernel's config file. See other
patch.
Signed-off-by: Andreas Gruenbacher <[email protected]>
Index: linux-2.6.11-rc1-bk6/scripts/kconfig/confdata.c
===================================================================
--- linux-2.6.11-rc1-bk6.orig/scripts/kconfig/confdata.c
+++ linux-2.6.11-rc1-bk6/scripts/kconfig/confdata.c
@@ -20,9 +20,6 @@ const char conf_defname[] = "arch/$ARCH/
const char *conf_confnames[] = {
".config",
- "/lib/modules/$UNAME_RELEASE/.config",
- "/etc/kernel-config",
- "/boot/config-$UNAME_RELEASE",
conf_defname,
NULL,
};
--
Andreas Gruenbacher <[email protected]>
SUSE Labs, SUSE LINUX PRODUCTS GMBH
Hi,
On Tue, 18 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.
bye, Roman
On Tue, 2005-01-18 at 21:15, Roman Zippel wrote:
> Hi,
>
> On Tue, 18 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 fundamentally broken to use a
semi-random configuration for a kernel source tree that may be
arbitrarily far apart. In the best case you notice that the
configuration doesn't work anymore. In the worst case you will fall flat
on your nose and only notice what happened after a long time.
It's not uncommon that users who build their own kernel modules often
are very clueless. Nevertheless we shouldn't cause them pain
unnecessarily.
Removing the running kernel's paths at least ensures that we don't get
arbitrary, unexpected results. I'd much prefer the user to be explicit
when he wants to clone the running kernel's configuration. That's what
patch 3/5 in this set does.
Cheers,
--
Andreas Gruenbacher <[email protected]>
SUSE Labs, SUSE LINUX GMBH
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.
> 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.
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.
bye, Roman
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 <[email protected]>
SUSE Labs, SUSE LINUX GMBH
Hi,
On Wed, 19 Jan 2005, Andreas Gruenbacher wrote:
> 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.
How is that more verbose?
Please provide an example config that worked under 2.4 but doesn't produce
a reasonable result under 2.6.
> > 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.
Why is that weird?
bye, Roman
Andreas Gruenbacher <[email protected]> writes:
> 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.
IIRC the vanilla kernel's arch/i386/defconfig is the "this config
boots Linus' machine" configuration (or has that changed recently?).
I certainly wouldn't call that a sane default ...
For vendor kernels with a generic defconfig that makes sense though.
Gerd
--
#define printk(args...) fprintf(stderr, ## args)