Dear All,

It seems I got enlightened in the topic of kernel reconfiguration from 
up to smp and back.

There are following facts:

1) currently the standard practice is to build the kernel with 
versioning (CONFIG_MODVERSIONS=y)
2) this way all modules have symbol kernel_version devined, that comes
from include/linux/module.h:

"kernel_version=" UTS_RELEASE;

in turn UTS_RELEASE comes from include/linux/version.h:

#define UTS_RELEASE "2.2.16-3smp"

3) file include/linux/version.h is generated by master Makefile when
target include/linux/version.h is used which is in turn called by
menuconfig target:

include/linux/version.h: ./Makefile
        @echo \#define UTS_RELEASE \"$(KERNELRELEASE)\" > .ver
... also here  LINUX_VERSION_CODE is defined
        @mv -f .ver $@

=================================================================
Note (!!!) that targets oldconfig, config and xconfig do not 
generate this file (include/linux/version.h) and this is a BUG IMHO

It's checked by code, as well in practice. The same till kernel 2.2.9,
and it is checked form kernel 2.2.16.

In practice - the only more or less working configuration command is
make menuconfig

====================================================================

4) variable KERNELRELEASE is defined in the same master Makefile as:

KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)

it can be seen very cleary, at the top of this file where these variables
are coming from, Makefile begings with them, for example for kernel
2.2.16-3 (RH6.2 U7):

VERSION = 2
PATCHLEVEL = 2
SUBLEVEL = 16
EXTRAVERSION = -3

5) Variables SMP_CONFIG are set when configuration has SMP support, and they
come from file .config:

CONFIG_SMP=y

in turn, file .congif is included by Makefile (sic!) only for the default
target, which is the same as 'all'.

6) It's easy to see that KERNELRELEASE, and therefore UTS_RELEASE will be 
always set to 2.2.16-3, unrelated to the value of SMP_CONFIG variable.

7) On the other hand, is we look at the values of kernel_version withing the
modules delivered with RH6.2 (i.e. installed with rpm command), then as we 
espect, versions for up mode value __module_kernel_version:

# strings -a /lib/modules/2.2.16-3/misc/ixj.o | grep kernel_version=
kernel_version=2.2.16-3

and with versions for smp:

# strings -a /lib/modules/2.2.16-3smp/misc/es1371.o | grep kernel_version=
kernel_version=2.2.16-3smp

============================================================================

The conclusion - the is a BUG in the congiguration system, and nobody plans to
fix it. There is a holy saying by Linux that there is no need to fix anything
there, because - why? It's OK as it is.

So, then RH are simply fixing EXTRAVERSION by hand in maste Makefile, then
build RPMs etc. This probably coincides with general party line, since there
is a dependency of target version.h from Makefile:

include/linux/version.h: ./Makefile

It should depend on .config, but .config is generated by target Menuconfig,
that has exacly visrion.h as a precondition:

menuconfig: include/linux/version.h symlinks
        $(MAKE) -C scripts/lxdialog all
        $(CONFIG_SHELL) scripts/Menuconfig arch/$(ARCH)/config.in


So, the design of this Makefile want's to be better in many respects - there
are no simple fixes.

Since our resouces are much more limited then RH's we offer this simplistic
path for Makefile. It's put right afer assignment of EXTRAVERSION variable:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# append 'smp' to EXTRAVERSION for SMP kernel congiguration
EXTRAVERSION :=$(EXTRAVERSION)`if grep -q "CONFIG_SMP=y" .config; then
echo smp; fi`
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The kernel configuration process then goes like that - since Makefile is
so dead and bad we are not trying to let him track the dependencies and clean 
every time till the initial state:

cp .config /tmp/linux.config
make distclean
cp /tmp/linux.config .
make menuconfig
make depend

How, we can build the kernel or other dirvers/modules. We can add lmlconfig
target that would do all that :-)

Maybe we can develop an intellectual script for fixing any Makefile, that would
add that line, checking that general Makefile structure is the same. 
Unfortunately, it's difficult to come with a patch, since the value assigned
to EXTRAVERSION changes all the time.

Vassili.