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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
