.version keeps being updated

.version keeps being updated

[Jean Delvare]

Hi all,

Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
an incremented version number, whether there has actually been any
change done to the code or configuration or not. This increases the
build time quite a bit.

I've tracked it down to include/linux/compile.h always being updated,
and this is because .version is updated. I couldn't find what is
causing .version to be updated each time though. Can anybody help
there? Was this change made on purpose or is this a bug which we should
fix?

Thanks,
-- 
Jean Delvare

Re: .version keeps being updated

[Gene Heskett]

On Tuesday 09 January 2007 04:20, Jean Delvare wrote:
>Hi all,
>
>Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
>an incremented version number, whether there has actually been any
>change done to the code or configuration or not. This increases the
>build time quite a bit.
>
>I've tracked it down to include/linux/compile.h always being updated,
>and this is because .version is updated. I couldn't find what is
>causing .version to be updated each time though. Can anybody help
>there? Was this change made on purpose or is this a bug which we should
>fix?
>
>Thanks,

I've not seen that here, Jean.  But then my 'makeit' script doesn't use a 
plain 'make' anyplace, always 'make bzimage' or 'make modules' & 'make 
modules install', etc.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.

Re: .version keeps being updated

[Andrey Borzenkov]

Jean Delvare wrote:

> Hi all,
> 
> Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> an incremented version number, whether there has actually been any
> change done to the code or configuration or not. This increases the
> build time quite a bit.
> 
> I've tracked it down to include/linux/compile.h always being updated,
> and this is because .version is updated. I couldn't find what is
> causing .version to be updated each time though. Can anybody help
> there? Was this change made on purpose or is this a bug which we should
> fix? 

I have been bitten by this as well; I have tracked it down to defining
CONFIG_KALLSYMS:

define rule_vmlinux__
        :
        $(if $(CONFIG_KALLSYMS),,+$(call cmd,vmlinux_version))

quiet_cmd_vmlinux_version = GEN     .version
      cmd_vmlinux_version = set -e;                     \
        if [ ! -r .version ]; then                      \
          rm -f .version;                               \
          echo 1 >.version;                             \
        else                                            \
          mv .version .old_version;                     \
          expr 0$$(cat .old_version) + 1 >.version;     \
        fi;                                             \
        $(MAKE) $(build)=init


 Pondering about it, this may be a feature not a bug. Let's assume you have
changed a single function name anywhere - you need to rebuild kallsyms
(ergo vmlinux) for that.

OTOH I do not know if kallsyms include also symbols from modules; if no,
this is indeed a bug.

-andrey

Re: .version keeps being updated

[Jean Delvare]

Hi Andrey,

On Tue, 09 Jan 2007 20:05:49 +0300, Andrey Borzenkov wrote:
> Jean Delvare wrote:
> > Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> > an incremented version number, whether there has actually been any
> > change done to the code or configuration or not. This increases the
> > build time quite a bit.
> > 
> > I've tracked it down to include/linux/compile.h always being updated,
> > and this is because .version is updated. I couldn't find what is
> > causing .version to be updated each time though. Can anybody help
> > there? Was this change made on purpose or is this a bug which we should
> > fix? 
> 
> I have been bitten by this as well; I have tracked it down to defining
> CONFIG_KALLSYMS:
> 
> define rule_vmlinux__
>         :
>         $(if $(CONFIG_KALLSYMS),,+$(call cmd,vmlinux_version))
> 
> quiet_cmd_vmlinux_version = GEN     .version
>       cmd_vmlinux_version = set -e;                     \
>         if [ ! -r .version ]; then                      \
>           rm -f .version;                               \
>           echo 1 >.version;                             \
>         else                                            \
>           mv .version .old_version;                     \
>           expr 0$$(cat .old_version) + 1 >.version;     \
>         fi;                                             \
>         $(MAKE) $(build)=init
> 
> 
>  Pondering about it, this may be a feature not a bug. Let's assume you have
> changed a single function name anywhere - you need to rebuild kallsyms
> (ergo vmlinux) for that.
> 
> OTOH I do not know if kallsyms include also symbols from modules; if no,
> this is indeed a bug.

I don't think this is the problem here. The kernel keeps being
recompiled even when _nothing_ has changed. This wasn't the case up to
2.6.19, while the code above has been there untouched since 2.6.14.

I tried a git bisect to find out what commit was reponsible for it, and
the winner is...

8993780a6e44fb4e7ed34e33458506a775356c6e is first bad commit
commit 8993780a6e44fb4e7ed34e33458506a775356c6e
Author: Linus Torvalds <torvalds@woody.osdl.org>
Date:   Mon Dec 11 09:28:46 2006 -0800

    Make SLES9 "get_kernel_version" work on the kernel binary again
    
    As reported by Andy Whitcroft, at least the SLES9 initrd build process
    depends on getting the kernel version from the kernel binary.  It does
    that by simply trawling the binary and looking for the signature of the
    "linux_banner" string (the string "Linux version " to be exact. Which
    is really broken in itself, but whatever..)
    
    That got broken when the string was changed to allow /proc/version to
    change the UTS release information dynamically, and "get_kernel_version"
    thus returned "%s" (see commit a2ee8649ba6d71416712e798276bf7c40b64e6e5:
    "[PATCH] Fix linux banner utsname information").
    
    This just restores "linux_banner" as a static string, which should fix
    the version finding.  And /proc/version simply uses a different string.
    
    To avoid wasting even that miniscule amount of memory, the early boot
    string should really be marked __initdata, but that just causes the same
    bug in SLES9 to re-appear, since it will then find other occurrences of
    "Linux version " first.
    
    Cc: Andy Whitcroft <apw@shadowen.org>
    Acked-by: Herbert Poetzl <herbert@13thfloor.at>
    Cc: Andi Kleen <ak@suse.de>
    Cc: Andrew Morton <akpm@osdl.org>
    Cc: Steve Fox <drfickle@us.ibm.com>
    Acked-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

:040000 040000 1dfdf42f80828c413baba65a1ce8b460c9712ded cdb83fd26232860493d9e993af467e1dff77da83 M      fs
:040000 040000 94ad8c94d5ce333ad8febdc508a37de768736a98 12bc13def90d15921d41d2b285854b3e157a970f M      include
:040000 040000 991e9baa5a61b998a0e4833e142d5c4f72d61729 5673719c3f6b47b329cfc9554c112077634a9b19 M      init

Reverting this from 2.6.20-rc1 made the build behave again, however I
found that reverting it from 2.6.20-rc2 did _not_ fix the problem. I
also had to revert the following patch to make things work as before
again:

commit ef129412b4cbd6686d0749612cb9b76e207271f4
Author: Andrew Morton <akpm@osdl.org>
Date:   Fri Dec 22 01:12:01 2006 -0800

    [PATCH] build compile.h earlier
    
    compile.h is created super-late in the build.  But proc_misc.c want to include
    it, and it's generally not sane to have a header file in include/linux be
    created at the end of the build: it's either not present or, worse, wrong for
    most of the build.
    
    So the patch arranges for compile.h to be built at the start of the build
    process.  It also consolidates the compile.h rules with those for version.h
    and utsname.h, so they all get built together.
    
    I hope.  My chances of having got this right are about 2%.
    
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: Andrew Morton <akpm@osdl.org>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

I can only second Andrew's commit's last sentence ;)

So, Linus, Andrew, can you please take a look and revert or fix what
needs to be? This new behavior of the kernel build system is likely to
make developers angry pretty quickly.

Thanks,
-- 
Jean Delvare

Re: .version keeps being updated

[Andrew Morton]

On Tue, 9 Jan 2007 21:44:21 +0100
Jean Delvare <khali@linux-fr.org> wrote:

> So, Linus, Andrew, can you please take a look and revert or fix what
> needs to be?

Am afraid to touch it.  Sam should be back on deck soon and will hopefully
have time to fix this stuff up.

> This new behavior of the kernel build system is likely to
> make developers angry pretty quickly.

That might motivate them to fix it ;)

Re: .version keeps being updated

[Linus Torvalds]

On Tue, 9 Jan 2007, Andrew Morton wrote:
> 
> > This new behavior of the kernel build system is likely to
> > make developers angry pretty quickly.
> 
> That might motivate them to fix it ;)

Actually, how about just removing the incrementing version count entirely?

I realize that it's really really old, and has been there basically since 
day one, but on the other hand, it's old not because it's fundamentally 
important, but because it's just been maintained. How about just dropping 
it entirely?

We have more useful _real_ versioning these days, with git commit ID's 
etc.

		Linus

Re: .version keeps being updated

[Andrew Morton]

On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:

> 
> 
> On Tue, 9 Jan 2007, Andrew Morton wrote:
> > 
> > > This new behavior of the kernel build system is likely to
> > > make developers angry pretty quickly.
> > 
> > That might motivate them to fix it ;)
> 
> Actually, how about just removing the incrementing version count entirely?

I use it pretty commonly to answer the question "did I remember to install
that new kernel I just built before I rebooted"?  By comparing `uname -a'
with $TOPDIR/.version.

Re: .version keeps being updated

[David Miller]

From: Andrew Morton <akpm@osdl.org>
Date: Tue, 9 Jan 2007 15:25:34 -0800

> On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
> Linus Torvalds <torvalds@osdl.org> wrote:
> 
> > On Tue, 9 Jan 2007, Andrew Morton wrote:
> > > 
> > > > This new behavior of the kernel build system is likely to
> > > > make developers angry pretty quickly.
> > > 
> > > That might motivate them to fix it ;)
> > 
> > Actually, how about just removing the incrementing version count entirely?
> 
> I use it pretty commonly to answer the question "did I remember to install
> that new kernel I just built before I rebooted"?  By comparing `uname -a'
> with $TOPDIR/.version.

Yeah me too :-)

Re: .version keeps being updated

[Andi Kleen]

Andrew Morton <akpm@osdl.org> writes:

> On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
> Linus Torvalds <torvalds@osdl.org> wrote:
> 
> > 
> > 
> > On Tue, 9 Jan 2007, Andrew Morton wrote:
> > > 
> > > > This new behavior of the kernel build system is likely to
> > > > make developers angry pretty quickly.
> > > 
> > > That might motivate them to fix it ;)
> > 
> > Actually, how about just removing the incrementing version count entirely?
> 
> I use it pretty commonly to answer the question "did I remember to install
> that new kernel I just built before I rebooted"?  By comparing `uname -a'
> with $TOPDIR/.version.

I even have scripts that require this to identify kernels. Please don't
remove it.

-Andi

Re: .version keeps being updated

[Herbert Poetzl]

On Tue, Jan 09, 2007 at 03:25:34PM -0800, Andrew Morton wrote:
> On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
> Linus Torvalds <torvalds@osdl.org> wrote:
> 
> > On Tue, 9 Jan 2007, Andrew Morton wrote:
> > > 
> > > > This new behavior of the kernel build system is likely to
> > > > make developers angry pretty quickly.
> > > 
> > > That might motivate them to fix it ;)
> > 
> > Actually, how about just removing the incrementing version count
> > entirely?
>
> I use it pretty commonly to answer the question "did I remember to
> install that new kernel I just built before I rebooted"? By comparing
> `uname -a' with $TOPDIR/.version.

second that!

please do not remove this useful 'debug' feature :)

TIA,
Herbert

Re: .version keeps being updated

[Jean Delvare]

Hi Linus, Andrew,

On Tue, 9 Jan 2007 15:25:34 -0800, Andrew Morton wrote:
> On Tue, 9 Jan 2007 15:21:51 -0800, Linus Torvalds wrote:
> > Actually, how about just removing the incrementing version count entirely?
>
> I use it pretty commonly to answer the question "did I remember to install
> that new kernel I just built before I rebooted"?  By comparing `uname -a'
> with $TOPDIR/.version.

This will no longer work with the current state of things, as
$TOPDIR/.version keeps increasing.

> > (...) We have more useful _real_ versioning these days, with git commit
> > ID's etc.

These are completely different types of IDs. The .version number is a
local build ID and changes when one applies a local patch, or simply
changes a config option, and recompiles his/her kernel. The git ID of
course doesn't.

>From the other comments in this thread, it looks like the build ID is
something many people are interested in, so we can't just drop it.

-- 
Jean Delvare

Re: .version keeps being updated

[Martin J. Bligh]

Andrew Morton wrote:
> On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
> Linus Torvalds <torvalds@osdl.org> wrote:
> 
>>
>> On Tue, 9 Jan 2007, Andrew Morton wrote:
>>>> This new behavior of the kernel build system is likely to
>>>> make developers angry pretty quickly.
>>> That might motivate them to fix it ;)
>> Actually, how about just removing the incrementing version count entirely?
> 
> I use it pretty commonly to answer the question "did I remember to install
> that new kernel I just built before I rebooted"?  By comparing `uname -a'
> with $TOPDIR/.version.

Yup, we need to do the same thing in automated testing. Especially when
you're doing lilo -R, and don't know if you ended up fscking or panicing
during attempted reboot to new kernel.

Better would be a checksum of the vmlinux vs the running kernel text,
but that seems to be impossible due to code rewriting. Could we embed
a checksum in a little /proc file for this?

M.

Re: .version keeps being updated

[Jean Delvare]

Hi Martin,

On Wed, 10 Jan 2007 08:52:24 -0800, Martin J. Bligh wrote:
> Andrew Morton wrote:
> > I use it pretty commonly to answer the question "did I remember to install
> > that new kernel I just built before I rebooted"?  By comparing `uname -a'
> > with $TOPDIR/.version.
> 
> Yup, we need to do the same thing in automated testing. Especially when
> you're doing lilo -R, and don't know if you ended up fscking or panicing
> during attempted reboot to new kernel.
> 
> Better would be a checksum of the vmlinux vs the running kernel text,
> but that seems to be impossible due to code rewriting. Could we embed
> a checksum in a little /proc file for this?

What would this allow that our current autoincrementing counter doesn't?

-- 
Jean Delvare

Re: .version keeps being updated

[Jan Engelhardt]

On Jan 9 2007 15:21, Linus Torvalds wrote:
>
>Actually, how about just removing the incrementing version count entirely?
>
>I realize that it's really really old, and has been there basically since 
>day one, but on the other hand, it's old not because it's fundamentally 
>important, but because it's just been maintained. How about just dropping 
>it entirely?
>
>We have more useful _real_ versioning these days, with git commit ID's 
>etc.

Like other people said, scripts rely on it. Not just kernel-build
scripts or thelike. Note that this local build ID is _also_ in
/proc/version, meaning that every possible script out there has
code/regex to skip or read that one field.

E.g.
($ver, $builder, $gcc, $id, $flags, $date) =
  ($_ =~ /^Linux version (\S+) \((\S+)\) \((.*)\) (#\d+) (.*) ((?:Mon|Tue|Wed|Thu|Fri|Sat|Sun).*)/);


Oh well we could also put a static "#0" in there, but it also has
its uses (see replies from other people).

	-`J'
-- 

Re: .version keeps being updated

[Roman Zippel]

Hi,

On Tue, 9 Jan 2007, Jean Delvare wrote:

> I tried a git bisect to find out what commit was reponsible for it, and
> the winner is...
> 
> 8993780a6e44fb4e7ed34e33458506a775356c6e is first bad commit
> commit 8993780a6e44fb4e7ed34e33458506a775356c6e
> Author: Linus Torvalds <torvalds@woody.osdl.org>
> Date:   Mon Dec 11 09:28:46 2006 -0800
> 
> [..]
> Reverting this from 2.6.20-rc1 made the build behave again, however I
> found that reverting it from 2.6.20-rc2 did _not_ fix the problem. I
> also had to revert the following patch to make things work as before
> again:
> 
> commit ef129412b4cbd6686d0749612cb9b76e207271f4
> Author: Andrew Morton <akpm@osdl.org>
> Date:   Fri Dec 22 01:12:01 2006 -0800

To make the list complete, this patch started all the mess:

commit a2ee8649ba6d71416712e798276bf7c40b64e6e5
Author: Herbert Poetzl <herbert@13thfloor.at>
Date:   Fri Dec 8 02:36:00 2006 -0800

    [PATCH] Fix linux banner utsname information

and this tries to fix a problem in Andrew's patch:

commit d449db98d5d7d90f29f9f6e091b0e1d996184df1
Author: Mikael Pettersson <mikpe@it.uu.se>
Date:   Fri Dec 29 16:48:09 2006 -0800

    [PATCH] fix mrproper incompleteness

The patch below reverts pretty much everything and instead introduces a 
seperate format string for proc.

bye, Roman



[PATCH] fix linux banner format string

Revert previous attempts at messing with the linux banner string and 
simply use a separate format string for proc.

Signed-off-by: Roman Zippel <zippel@linux-m68k.org>

---
 Makefile               |   31 +++++++++----------------------
 fs/proc/proc_misc.c    |    8 +-------
 include/linux/kernel.h |    3 +++
 init/Makefile          |   10 +++++++++-
 init/main.c            |    8 --------
 init/version.c         |   10 ++++++++++
 6 files changed, 32 insertions(+), 38 deletions(-)

Index: linux-2.6-git/fs/proc/proc_misc.c
===================================================================
--- linux-2.6-git.orig/fs/proc/proc_misc.c	2007-01-10 04:27:23.000000000 +0100
+++ linux-2.6-git/fs/proc/proc_misc.c	2007-01-10 04:33:01.000000000 +0100
@@ -47,7 +47,6 @@
 #include <linux/vmalloc.h>
 #include <linux/crash_dump.h>
 #include <linux/pid_namespace.h>
-#include <linux/compile.h>
 #include <asm/uaccess.h>
 #include <asm/pgtable.h>
 #include <asm/io.h>
@@ -254,12 +253,7 @@ static int version_read_proc(char *page,
 {
 	int len;
 
-	/* FIXED STRING! Don't touch! */
-	len = snprintf(page, PAGE_SIZE,
-		"%s version %s"
-		" (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ")"
-		" (" LINUX_COMPILER ")"
-		" %s\n",
+	len = snprintf(page, PAGE_SIZE, linux_proc_banner,
 		utsname()->sysname,
 		utsname()->release,
 		utsname()->version);
Index: linux-2.6-git/include/linux/kernel.h
===================================================================
--- linux-2.6-git.orig/include/linux/kernel.h	2007-01-10 04:26:37.000000000 +0100
+++ linux-2.6-git/include/linux/kernel.h	2007-01-10 04:27:05.000000000 +0100
@@ -17,6 +17,9 @@
 #include <asm/byteorder.h>
 #include <asm/bug.h>
 
+extern const char linux_banner[];
+extern const char linux_proc_banner[];
+
 #define INT_MAX		((int)(~0U>>1))
 #define INT_MIN		(-INT_MAX - 1)
 #define UINT_MAX	(~0U)
Index: linux-2.6-git/init/main.c
===================================================================
--- linux-2.6-git.orig/init/main.c	2007-01-10 04:34:02.000000000 +0100
+++ linux-2.6-git/init/main.c	2007-01-10 14:20:02.000000000 +0100
@@ -50,9 +50,7 @@
 #include <linux/buffer_head.h>
 #include <linux/debug_locks.h>
 #include <linux/lockdep.h>
-#include <linux/utsrelease.h>
 #include <linux/pid_namespace.h>
-#include <linux/compile.h>
 #include <linux/device.h>
 
 #include <asm/io.h>
@@ -482,12 +480,6 @@ void __init __attribute__((weak)) smp_se
 {
 }
 
-static const char linux_banner[] =
-	"Linux version " UTS_RELEASE
-	" (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ")"
-	" (" LINUX_COMPILER ")"
-	" " UTS_VERSION "\n";
-
 asmlinkage void __init start_kernel(void)
 {
 	char * command_line;
Index: linux-2.6-git/init/version.c
===================================================================
--- linux-2.6-git.orig/init/version.c	2007-01-10 04:29:20.000000000 +0100
+++ linux-2.6-git/init/version.c	2007-01-10 04:41:11.000000000 +0100
@@ -33,3 +33,13 @@ struct uts_namespace init_uts_ns = {
 	},
 };
 EXPORT_SYMBOL_GPL(init_uts_ns);
+
+/* FIXED STRING! Don't touch! */
+const char __init linux_banner[] =
+	"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
+	LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
+
+const char linux_proc_banner[] =
+	"%s version %s"
+	" (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ")"
+	" (" LINUX_COMPILER ") %s\n";
Index: linux-2.6-git/init/Makefile
===================================================================
--- linux-2.6-git.orig/init/Makefile	2007-01-10 04:44:59.000000000 +0100
+++ linux-2.6-git/init/Makefile	2007-01-10 14:06:15.000000000 +0100
@@ -15,6 +15,14 @@ clean-files := ../include/linux/compile.
 
 # dependencies on generated files need to be listed explicitly
 
-$(obj)/main.o: include/linux/compile.h
 $(obj)/version.o: include/linux/compile.h
 
+# compile.h changes depending on hostname, generation number, etc,
+# so we regenerate it always.
+# mkcompile_h will make sure to only update the
+# actual file if its content has changed.
+
+include/linux/compile.h: FORCE
+	@echo '  CHK     $@'
+	$(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkcompile_h $@ \
+	"$(UTS_MACHINE)" "$(CONFIG_SMP)" "$(CONFIG_PREEMPT)" "$(CC) $(CFLAGS)"
Index: linux-2.6-git/Makefile
===================================================================
--- linux-2.6-git.orig/Makefile	2007-01-10 14:01:24.000000000 +0100
+++ linux-2.6-git/Makefile	2007-01-10 14:06:15.000000000 +0100
@@ -368,14 +368,10 @@ endif
 # Detect when mixed targets is specified, and make a second invocation
 # of make so .config is not included in this case either (for *config).
 
-PHONY += generated_headers
-
-generated_headers: include/linux/version.h include/linux/compile.h \
-		include/linux/utsrelease.h
-
-no-dot-config-targets := generated_headers clean mrproper distclean \
+no-dot-config-targets := clean mrproper distclean \
 			 cscope TAGS tags help %docs check% \
-			 headers_% kernelrelease kernelversion
+			 include/linux/version.h headers_% \
+			 kernelrelease kernelversion
 
 config-targets := 0
 mixed-targets  := 0
@@ -738,16 +734,6 @@ debug_kallsyms: .tmp_map$(last_kallsyms)
 
 endif # ifdef CONFIG_KALLSYMS
 
-# compile.h changes depending on hostname, generation number, etc,
-# so we regenerate it always.
-# mkcompile_h will make sure to only update the
-# actual file if its content has changed.
-
-include/linux/compile.h: FORCE
-	@echo '  CHK     $@'
-	$(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkcompile_h $@ \
-	"$(UTS_MACHINE)" "$(CONFIG_SMP)" "$(CONFIG_PREEMPT)" "$(CC) $(CFLAGS)"
-
 # vmlinux image - including updated kernel symbols
 vmlinux: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) $(kallsyms.o) FORCE
 ifdef CONFIG_HEADERS_CHECK
@@ -866,8 +852,8 @@ endif
 # prepare2 creates a makefile if using a separate output directory
 prepare2: prepare3 outputmakefile
 
-prepare1: prepare2 generated_headers include/asm include/config/auto.conf
-
+prepare1: prepare2 include/linux/version.h include/linux/utsrelease.h \
+                   include/asm include/config/auto.conf
 ifneq ($(KBUILD_MODULES),)
 	$(Q)mkdir -p $(MODVERDIR)
 	$(Q)rm -f $(MODVERDIR)/*
@@ -936,14 +922,14 @@ export INSTALL_HDR_PATH
 HDRARCHES=$(filter-out generic,$(patsubst $(srctree)/include/asm-%/Kbuild,%,$(wildcard $(srctree)/include/asm-*/Kbuild)))
 
 PHONY += headers_install_all
-headers_install_all: generated_headers scripts_basic FORCE
+headers_install_all: include/linux/version.h scripts_basic FORCE
 	$(Q)$(MAKE) $(build)=scripts scripts/unifdef
 	$(Q)for arch in $(HDRARCHES); do \
 	 $(MAKE) ARCH=$$arch -f $(srctree)/scripts/Makefile.headersinst obj=include BIASMDIR=-bi-$$arch ;\
 	 done
 
 PHONY += headers_install
-headers_install: generated_headers scripts_basic FORCE
+headers_install: include/linux/version.h scripts_basic FORCE
 	@if [ ! -r $(srctree)/include/asm-$(ARCH)/Kbuild ]; then \
 	  echo '*** Error: Headers not exportable for this architecture ($(ARCH))'; \
 	  exit 1 ; fi
@@ -1040,7 +1026,8 @@ CLEAN_FILES +=	vmlinux System.map \
 # Directories & files removed with 'make mrproper'
 MRPROPER_DIRS  += include/config include2 usr/include
 MRPROPER_FILES += .config .config.old include/asm .version .old_version \
-                  include/linux/autoconf.h include/linux/utsrelease.h include/linux/version.h \
+                  include/linux/autoconf.h include/linux/version.h      \
+                  include/linux/utsrelease.h                            \
 		  Module.symvers tags TAGS cscope*
 
 # clean - Delete most, but leave enough to build external modules

Re: .version keeps being updated

[Olaf Hering]

On Wed, Jan 10, Roman Zippel wrote:

> [PATCH] fix linux banner format string
> 
> Revert previous attempts at messing with the linux banner string and 
> simply use a separate format string for proc.
> 
> Signed-off-by: Roman Zippel <zippel@linux-m68k.org>

Acked-by: Olaf Hering <olaf@aepfle.de>

Re: .version keeps being updated

[Jean Delvare]

Hi Roman,

On Wed, 10 Jan 2007 14:45:28 +0100 (CET), Roman Zippel wrote:
> On Tue, 9 Jan 2007, Jean Delvare wrote:
> 
> > I tried a git bisect to find out what commit was reponsible for it, and
> > the winner is...
> > 
> > 8993780a6e44fb4e7ed34e33458506a775356c6e is first bad commit
> > commit 8993780a6e44fb4e7ed34e33458506a775356c6e
> > Author: Linus Torvalds <torvalds@woody.osdl.org>
> > Date:   Mon Dec 11 09:28:46 2006 -0800
> > 
> > [..]
> > Reverting this from 2.6.20-rc1 made the build behave again, however I
> > found that reverting it from 2.6.20-rc2 did _not_ fix the problem. I
> > also had to revert the following patch to make things work as before
> > again:
> > 
> > commit ef129412b4cbd6686d0749612cb9b76e207271f4
> > Author: Andrew Morton <akpm@osdl.org>
> > Date:   Fri Dec 22 01:12:01 2006 -0800
> 
> To make the list complete, this patch started all the mess:
> 
> commit a2ee8649ba6d71416712e798276bf7c40b64e6e5
> Author: Herbert Poetzl <herbert@13thfloor.at>
> Date:   Fri Dec 8 02:36:00 2006 -0800
> 
>     [PATCH] Fix linux banner utsname information
> 
> and this tries to fix a problem in Andrew's patch:
> 
> commit d449db98d5d7d90f29f9f6e091b0e1d996184df1
> Author: Mikael Pettersson <mikpe@it.uu.se>
> Date:   Fri Dec 29 16:48:09 2006 -0800
> 
>     [PATCH] fix mrproper incompleteness
> 
> The patch below reverts pretty much everything and instead introduces a 
> seperate format string for proc.
> (...)
> [PATCH] fix linux banner format string
> 
> Revert previous attempts at messing with the linux banner string and 
> simply use a separate format string for proc.

This fixes the problem I reported. Thanks Roman!

Linus, Andrew, if Roman's patch looks OK to you, can it please be
applied before 2.6.20 is released?

Thanks,
-- 
Jean Delvare

Re: .version keeps being updated

[Linus Torvalds]

On Wed, 10 Jan 2007, Jean Delvare wrote:
> 
> This fixes the problem I reported. Thanks Roman!
> 
> Linus, Andrew, if Roman's patch looks OK to you, can it please be
> applied before 2.6.20 is released?

I applied it, but looking closer at it, it becomes clear that Roman didn't 
understand the problem with that patch.

This part:

	const char __init linux_banner[] =

CANNOT work, because the stupid SuSE tool that look into the kernel binary 
searches for "Linux version " as the thing, and as such the "linux_banner" 
has to be the _first_ thing to trigger it for it to work.

Which is why "__init" is wrong. It causes the linker to either put it at 
the end of the thing (which would break the SuSE tool). Alternatively it 
causes section mismatch problems ("init" and "const" don't work that well 
together), in which case it might work, but only due to toolchain bugs.

Grr.

		Linus

Re: .version keeps being updated

[Olaf Hering]

On Wed, Jan 10, Linus Torvalds wrote:

> Grr.

It did work for me for some reason, but I was wondering why it did work.

Cant we just invent a .data.uts section and put that into the
i386/x86_64/ia64/s390/powerpc vmlinux.lds.S files?
'"Linux version " UTS_RELEASE' in version.c

Re: .version keeps being updated

[Olaf Hering]

On Wed, Jan 10, Olaf Hering wrote:

> On Wed, Jan 10, Linus Torvalds wrote:
> 
> > Grr.
> 
> It did work for me for some reason, but I was wondering why it did work.

with such a change, it will always be first. Tested on powerpc.
I could even add an ELF parser and look for the first bytes in the
.rodata section.

diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 9fcc8d9..2050d8e 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -11,6 +11,11 @@ #define ALIGN_FUNCTION()  . = ALIGN(8)
 
 #define RODATA								\
 	. = ALIGN(4096);						\
+									\
+	.rodata.uts         : AT(ADDR(.data.uts) - LOAD_OFFSET) {	\
+		*(.data.uts)						\
+	}								\
+									\
 	.rodata           : AT(ADDR(.rodata) - LOAD_OFFSET) {		\
 		VMLINUX_SYMBOL(__start_rodata) = .;			\
 		*(.rodata) *(.rodata.*)					\
diff --git a/init/version.c b/init/version.c
index 9d96d36..03f5916 100644
--- a/init/version.c
+++ b/init/version.c
@@ -19,6 +19,8 @@ #define version_string(a) version(a)
 
 int version_string(LINUX_VERSION_CODE);
 
+const char __attribute__ ((__section__ (".rodata.uts"))) get_kernel_version[] = "fiXme Linux version " UTS_RELEASE;
+
 struct uts_namespace init_uts_ns = {
 	.kref = {
 		.refcount	= ATOMIC_INIT(2),

Re: .version keeps being updated

[Jan Engelhardt]

On Jan 10 2007 21:02, Olaf Hering wrote:
>On Wed, Jan 10, Olaf Hering wrote:
>
>with such a change, it will always be first. Tested on powerpc.
>I could even add an ELF parser and look for the first bytes in the
>.rodata section.

With such a change, you would not need to grep for it. You could use
binutils on it. `objdump -sj .rodata.uts vmlinux` would be a start.
Maybe not the prettiest output, but guaranteed to contain only the
banner.


	-`J'
-- 

Re: .version keeps being updated

[Segher Boessenkool]

> With such a change, you would not need to grep for it. You could use
> binutils on it. `objdump -sj .rodata.uts vmlinux` would be a start.
> Maybe not the prettiest output, but guaranteed to contain only the
> banner.

objcopy -j .rodata.uts -O binary vmlinux >(the-checker-script)


Segher

Re: .version keeps being updated

[Jan Engelhardt]

>> With such a change, you would not need to grep for it. You could use
>> binutils on it. `objdump -sj .rodata.uts vmlinux` would be a start.
>> Maybe not the prettiest output, but guaranteed to contain only the
>> banner.
>
> objcopy -j .rodata.uts -O binary vmlinux >(the-checker-script)

For some reason that does not work.


  ../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko 
  objcopy: stvfMiji: Permission denied

Why does it want to create a file there? This one works better:

  $ objcopy -j .modinfo -O binary sonypi.ko /dev/stdout

has more success.

	-`J'
-- 

Re: .version keeps being updated

[Andreas Schwab]

Jan Engelhardt <jengelh@linux01.gwdg.de> writes:

>   ../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko 
>   objcopy: stvfMiji: Permission denied
>
> Why does it want to create a file there? This one works better:

objcopy works in-place when only one file argument is passed.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: .version keeps being updated

[Segher Boessenkool]

>>   ../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
>>   objcopy: stvfMiji: Permission denied
>>
>> Why does it want to create a file there? This one works better:
>
> objcopy works in-place when only one file argument is passed.

Yeah.  The >(...) syntax in my example provides such a file;
of course it's horribly broken in bash 3.x like so many other
things, but that's a different issue ;-)


Segher

Re: .version keeps being updated

[Jan Engelhardt]

On Jan 11 2007 18:39, Segher Boessenkool wrote:
>
>> > ../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
>> > objcopy: stvfMiji: Permission denied
>> > 
>> > Why does it want to create a file there? This one works better:
>> 
>> objcopy works in-place when only one file argument is passed.
>
> Yeah.  The >(...) syntax in my example provides such a file;
> of course it's horribly broken in bash 3.x like so many other
> things, but that's a different issue ;-)

I took () to be substituted, did not know you intended to write >(grep ...)
And that's not broken at all.


	-`J'
-- 

Re: .version keeps being updated

[Linus Torvalds]

On Wed, 10 Jan 2007, Olaf Hering wrote:
>
> On Wed, Jan 10, Linus Torvalds wrote:
> 
> > Grr.
> 
> It did work for me for some reason, but I was wondering why it did work.

Because you didn't have CIFS compiled in? Right now that's the only other 
module that would trigger that particular string in memory, I think. So 
purely by luck.

> Cant we just invent a .data.uts section and put that into the
> i386/x86_64/ia64/s390/powerpc vmlinux.lds.S files?
> '"Linux version " UTS_RELEASE' in version.c

I'd rather have the problem fixed by just not doing the binary scrounging 
at all, or at the very least making the pattern-matching so strict that 
there's no way other "Linux version " strings can trigger..

		Linus

Re: .version keeps being updated

[Linus Torvalds]

On Wed, 10 Jan 2007, Linus Torvalds wrote:
> 
> Which is why "__init" is wrong. It causes the linker to either put it at 
> the end of the thing (which would break the SuSE tool). Alternatively it 
> causes section mismatch problems ("init" and "const" don't work that well 
> together), in which case it might work, but only due to toolchain bugs.
> 
> Grr.

Does anybody have the silly SuSE kernel version tool, and could test that 
without the "__init" it all actually works?

		Linus

Re: .version keeps being updated

[Andy Whitcroft]

Linus Torvalds wrote:
> 
> On Wed, 10 Jan 2007, Linus Torvalds wrote:
>> Which is why "__init" is wrong. It causes the linker to either put it at 
>> the end of the thing (which would break the SuSE tool). Alternatively it 
>> causes section mismatch problems ("init" and "const" don't work that well 
>> together), in which case it might work, but only due to toolchain bugs.
>>
>> Grr.
> 
> Does anybody have the silly SuSE kernel version tool, and could test that 
> without the "__init" it all actually works?

Sure, will do.

-apw

Re: .version keeps being updated

[Andy Whitcroft]

Linus Torvalds wrote:
> 
> On Wed, 10 Jan 2007, Linus Torvalds wrote:
>> Which is why "__init" is wrong. It causes the linker to either put it at 
>> the end of the thing (which would break the SuSE tool). Alternatively it 
>> causes section mismatch problems ("init" and "const" don't work that well 
>> together), in which case it might work, but only due to toolchain bugs.
>>
>> Grr.
> 
> Does anybody have the silly SuSE kernel version tool, and could test that 
> without the "__init" it all actually works?

Ok, testing of this worked here across the board.    All using the same
configs we used for the last round of testing on this issue.  The main
problem machine ppc64 on SLES9 with CIFS enabled passes with this patch
plus __init removed.

Results on TKO.

Acked-by: Andy Whitcroft <apw@shadowen.org>

-apw

Re: .version keeps being updated

[Roman Zippel]

Hi,

On Wed, 10 Jan 2007, Linus Torvalds wrote:

> This part:
> 
> 	const char __init linux_banner[] =
> 
> CANNOT work, because the stupid SuSE tool that look into the kernel binary 
> searches for "Linux version " as the thing, and as such the "linux_banner" 
> has to be the _first_ thing to trigger it for it to work.

Unless the SuSE tool is completely stupid, it should actually work:

$ strings vmlinux | grep "Linux version"
Linux version 2.6.20-rc3-git7 (roman@squid) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #7 SMP Wed Jan 10 14:20:10 CET 2007
$

> Which is why "__init" is wrong. It causes the linker to either put it at 
> the end of the thing (which would break the SuSE tool). Alternatively it 
> causes section mismatch problems ("init" and "const" don't work that well 
> together), in which case it might work, but only due to toolchain bugs.

The const could be dropped, but it shouldn't hurt much either...

bye, Roman

Re: .version keeps being updated

[Andy Whitcroft]

Roman Zippel wrote:
> Hi,
> 
> On Wed, 10 Jan 2007, Linus Torvalds wrote:
> 
>> This part:
>>
>> 	const char __init linux_banner[] =
>>
>> CANNOT work, because the stupid SuSE tool that look into the kernel binary 
>> searches for "Linux version " as the thing, and as such the "linux_banner" 
>> has to be the _first_ thing to trigger it for it to work.
> 
> Unless the SuSE tool is completely stupid, it should actually work:
> 
> $ strings vmlinux | grep "Linux version"
> Linux version 2.6.20-rc3-git7 (roman@squid) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #7 SMP Wed Jan 10 14:20:10 CET 2007
> $

Try compiling a kernel with CIFS enabled and you will find the output
somewhat different.  And herein lies the rub, if the proc string is
__initdata then it falls to the bottom, and the tool takes the first
entry starting from 'Linux version ', which matches these incorrect
lines and the tool fails.

> 
>> Which is why "__init" is wrong. It causes the linker to either put it at 
>> the end of the thing (which would break the SuSE tool). Alternatively it 
>> causes section mismatch problems ("init" and "const" don't work that well 
>> together), in which case it might work, but only due to toolchain bugs.
> 
> The const could be dropped, but it shouldn't hurt much either...

Longer term I do wonder if the linker section idea mooted elsewhere in
this thread would fly.

-apw

Re: .version keeps being updated

[Linus Torvalds]

On Thu, 11 Jan 2007, Roman Zippel wrote:
> 
> Unless the SuSE tool is completely stupid, it should actually work:
> 
> $ strings vmlinux | grep "Linux version"
> Linux version 2.6.20-rc3-git7 (roman@squid) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #7 SMP Wed Jan 10 14:20:10 CET 2007

How about you do

	git grep '".*Linux version .*"'

instead, and realize that it depends on your configuration option. Notably 
CIFS.

In short: __init is actually a real *BUG*.

		Linus

Re: .version keeps being updated

[Luca Tettamanti]

Jean Delvare <khali@linux-fr.org> ha scritto:
> Hi all,

Hi Jean,

> Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> an incremented version number, whether there has actually been any
> change done to the code or configuration or not. This increases the
> build time quite a bit.
> 
> I've tracked it down to include/linux/compile.h always being updated,
> and this is because .version is updated. I couldn't find what is
> causing .version to be updated each time though. Can anybody help
> there? Was this change made on purpose or is this a bug which we should
> fix?

kronos:~/src/linux-2.6.git$ cat ../linux-build-git/include/linux/compile.h
/* This file is auto generated, version 14 */
/* SMP PREEMPT */
#define UTS_MACHINE "i386"
#define UTS_VERSION "#14 SMP PREEMPT Tue Jan 9 22:45:18 CET 2007"
#define LINUX_COMPILE_TIME "22:45:18"
#define LINUX_COMPILE_BY "kronos"
#define LINUX_COMPILE_HOST "dreamland.darkstar.lan"
#define LINUX_COMPILE_DOMAIN "darkstar.lan"
#define LINUX_COMPILER "gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)"

LINUX_COMPILE_TIME and UTS_VERSION differs at each rebuild. UTS_VERSION
is responsible of rebuilding fs/proc/proc_misc.o; init/main.o uses just
about everything, init/version.o requires UTS_VERSION.

I don't think it's a regression from earlier kernels though, is it?

kronos:~/src/linux-2.6.git$ make -j3 V=2 O=../linux-build-git/
  GEN     /home/kronos/src/linux-build-git/Makefile
  CHK     include/linux/version.h
  CHK     include/linux/compile.h
  CHK     include/linux/utsrelease.h
  Using /home/kronos/src/linux-2.6.git as source for kernel
  UPD     include/linux/compile.h
  CC      init/main.o - due to: include/linux/compile.h
  CC      init/version.o - due to: include/linux/compile.h
  LD      init/built-in.o - due to: init/main.o init/version.o
  CC      fs/proc/proc_misc.o - due to: include/linux/compile.h
  LD      fs/proc/proc.o - due to: fs/proc/proc_misc.o
  LD      fs/proc/built-in.o - due to: fs/proc/proc.o
  LD      fs/built-in.o - due to: fs/proc/built-in.o
  GEN     .version - due to: init/built-in.o fs/built-in.o
  LD      .tmp_vmlinux1 - due to: init/built-in.o fs/built-in.o
  KSYM    .tmp_kallsyms1.S - due to: .tmp_vmlinux1
  AS      .tmp_kallsyms1.o - due to: .tmp_kallsyms1.S
  LD      .tmp_vmlinux2 - due to: init/built-in.o fs/built-in.o .tmp_kallsyms1.o
  KSYM    .tmp_kallsyms2.S - due to: .tmp_vmlinux2
  AS      .tmp_kallsyms2.o - due to: .tmp_kallsyms2.S
  LD      vmlinux - due to: init/built-in.o fs/built-in.o .tmp_kallsyms2.o
  SYSMAP  System.map
  SYSMAP  .tmp_System.map
  MODPOST vmlinux - due to vmlinux not in $(targets)
  Building modules, stage 2.
  AS      arch/i386/boot/setup.o - due to: include/linux/compile.h
  OBJCOPY arch/i386/boot/compressed/vmlinux.bin - due to: vmlinux
  GZIP    arch/i386/boot/compressed/vmlinux.bin.gz - due to: arch/i386/boot/compressed/vmlinux.bin
  MODPOST 130 modules - due to target is PHONY
  LD      arch/i386/boot/compressed/piggy.o - due to: arch/i386/boot/compressed/vmlinux.bin.gz
  LD      arch/i386/boot/compressed/vmlinux - due to: arch/i386/boot/compressed/piggy.o
  LD      arch/i386/boot/setup - due to: arch/i386/boot/setup.o
  OBJCOPY arch/i386/boot/vmlinux.bin - due to: arch/i386/boot/compressed/vmlinux
  BUILD   arch/i386/boot/bzImage - due to: arch/i386/boot/setup arch/i386/boot/vmlinux.bin
Root device is (254, 0)
Boot sector 512 bytes.
Setup is 6959 bytes.
System is 1567 kB
Kernel: arch/i386/boot/bzImage is ready  (#16)

Luca
-- 
La somma dell'intelligenza sulla terra e` una costante.
La popolazione e` in aumento.

Re: .version keeps being updated

[Jean Delvare]

Hi Luca,

On Tue, 9 Jan 2007 22:55:27 +0100, Luca Tettamanti wrote:
> Jean Delvare <khali@linux-fr.org> ha scritto:
> > Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> > an incremented version number, whether there has actually been any
> > change done to the code or configuration or not. This increases the
> > build time quite a bit.
> > 
> > I've tracked it down to include/linux/compile.h always being updated,
> > and this is because .version is updated. I couldn't find what is
> > causing .version to be updated each time though. Can anybody help
> > there? Was this change made on purpose or is this a bug which we should
> > fix?
> 
> kronos:~/src/linux-2.6.git$ cat ../linux-build-git/include/linux/compile.h
> /* This file is auto generated, version 14 */
> /* SMP PREEMPT */
> #define UTS_MACHINE "i386"
> #define UTS_VERSION "#14 SMP PREEMPT Tue Jan 9 22:45:18 CET 2007"
> #define LINUX_COMPILE_TIME "22:45:18"
> #define LINUX_COMPILE_BY "kronos"
> #define LINUX_COMPILE_HOST "dreamland.darkstar.lan"
> #define LINUX_COMPILE_DOMAIN "darkstar.lan"
> #define LINUX_COMPILER "gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)"
> 
> LINUX_COMPILE_TIME and UTS_VERSION differs at each rebuild. UTS_VERSION
> is responsible of rebuilding fs/proc/proc_misc.o; init/main.o uses just
> about everything, init/version.o requires UTS_VERSION.

That's not quite true, LINUX_COMPILE_TIME and UTS_VERSION are
explicitely excluded from the comparison when checking whether
linux/compile.h changed. This is done in scripts/mkcompile_h, and I
believe this part works properly. This script wasn't modified recently.

> I don't think it's a regression from earlier kernels though, is it?

It definitely is, which is why I am reporting it and am asking for it
to be fixed. I isolated the two responsible commits elsewhere in the
thread.

Thanks,
-- 
Jean Delvare

Re: .version keeps being updated

[Willy Tarreau]

Hi Jean !

On Tue, Jan 09, 2007 at 10:20:57AM +0100, Jean Delvare wrote:
> Hi all,
> 
> Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> an incremented version number, whether there has actually been any
> change done to the code or configuration or not. This increases the
> build time quite a bit.
> 
> I've tracked it down to include/linux/compile.h always being updated,
> and this is because .version is updated. I couldn't find what is
> causing .version to be updated each time though. Can anybody help
> there? Was this change made on purpose or is this a bug which we should
> fix?

it contains the build number (#X). You have it in the Makefile :
"expr 0$$(cat .old_version) + 1 >.version". I think you can block it
with a "chattr +i .version" and see if make complains.

Regards,
Willy