Hi,

With the following commit running "make modules_install install" over
sshfs (and I suppose nfs) is extremely painful:

commit fb994ecc2b1c214951366c2ba5d8b121f0010d1f
Author: Greg Thelen <gthelen@google.com>
Date:   Wed May 5 10:41:44 2010 -0700

    kbuild: Fix checking of scm-identifier variable
    
    I'm looking Makefile in the -mm branch (dated 2010-04-28-16-53) and
    seeing what looks like a bug in the checking of scm-identifier.  The
    "ifneq ($scm-identifier)" seems to always execute "ifeq
    ($(LOCALVERSION,)) ...".  This patch fixes the checking of
    scm-identifier.
    
    Signed-off-by: Greg Thelen <gthelen@google.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Signed-off-by: Michal Marek <mmarek@suse.cz>

I compile my kernel on my workstation and then mount working tree over
sshfs and install on my laptop over wireless. It worked well for the
last few years but the latest changeset slows this process down to a
crawl - traversing git repository over the network is not the fastest
process out there. Any cfhance we could generate the tag at compile time
as opposed to install time?

Thanks.

-- 
Dmitry
--

[ message continues ]

...

Commit 85a256d8 and this one just exposed a problem we had before with
CONFIG_LOCALVERSION_AUTO, namely that the Makefile computes the release
string on _every_ invocation:

$ strace -feexecve make help 2>&1 | grep -v ' -1 ' | grep git
[pid 13788] execve("/usr/bin/git", ["git", "rev-parse", "--verify",
"--short", "HEAD"], [/* 88 vars */]) = 0
[pid 13790] execve("/usr/bin/git", ["git", "describe", "--exact-match"],
[/* 88 vars */]) = 0
[pid 13792] execve("/usr/bin/git", ["git", "describe"], [/* 88 vars */]) = 0
[pid 13795] execve("/usr/bin/git", ["git", "config", "--get",
"svn-remote.svn.url"], [/* 88 vars */]) = 0
[pid 13796] execve("/usr/bin/git", ["git", "update-index", "--refresh",
"--unmerged"], [/* 88 vars */]) = 0
[pid 13797] execve("/usr/bin/git", ["git", "diff-index", "--name-only",

The Makefile already stores the string in include/config/kernel.release
during 'make prepare', but it is nevertheless recomputed every time.
Need to clean this up.

Michal
--

[ message continues ]

Now that we run scripts/setlocalversion during every build, it makes
sense to move all the localversion logic there. This cleans up the
toplevel Makefile and also makes sure that the script is called only
once in 'make prepare' (previously, it would be called every time due to
a variable expansion in an ifneq statement). No user-visible change is
intended, unless one runs the setlocalversion script directly.

Reported-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Nico Schottelius <nico-linuxsetlocalversion@schottelius.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
---

I tried to test this in various scenarios, but if anyone of you could give
it a try, that would be great. The patch is against 2.6.35-rc3.

---
 Makefile                 |   74 +------------------
 scripts/package/Makefile |    2 +-
 scripts/setlocalversion  |  179 ++++++++++++++++++++++++++++++++++------------
 3 files changed, 136 insertions(+), 119 deletions(-)

diff --git a/Makefile b/Makefile
index d49d96c..f6d2cb2 100644
--- a/Makefile
+++ b/Makefile
@@ -883,80 +883,12 @@ PHONY += $(vmlinux-dirs)
 $(vmlinux-dirs): prepare scripts
 	$(Q)$(MAKE) $(build)=$@
 
-# Build the kernel release string
-#
-# The KERNELRELEASE value built here is stored in the file
-# include/config/kernel.release, and is used when executing several
-# make targets, such as "make install" or "make modules_install."
-#
-# The eventual kernel release string consists of the following fields,
-# shown in a hierarchical format to show how smaller parts are concatenated
-# to form the larger and final value, with values coming from places like
-# the Makefile, kernel config options, make command line options and/or
-# SCM tag information.
-#
-#	$(KERNELVERSION)
-#	  $(VERSION)			eg, 2
-#	  $(PATCHLEVEL)			eg, 6
-#	  $(SUBLEVEL)			eg, 18
-#	  $(EXTRAVERSION)		eg, -rc6
-#	$(localver-full)
-#	  $(localver)
-#	    localversion*		(files ...
[ message continues ]

I agree it would be better to move this to scripts/setlocalversion, thanks 
for looking into it.  I'll put this into my build cycles and see if it 
causes any issues in my workflow that is known to be good with 2.6.35-rc3.  
Since this is 2.6.36 material, it seems like we have some time.
--

[ message continues ]

No, I am sorry, it is not .36 material as the building on remote box was
messed up in .35 cycle.

-- 
Dmitry
--

[ message continues ]

Seems to be working for me, I do not need to go and fetch coffee while
installig newly compiled kernel anymore.

Thanks for your help Michal.

-- 
Dmitry
--

[ message continues ]

Michal,

Any chance this could be merged in 2.6.35? Without the patch installing
over the network is not really an option anymore.

Thanks.

-- 
Dmitry
--

[ message continues ]

I now found that my patch breaks 'make LOCALVERSION=... '. The following
patch should fix it.

Michal


commit 0a564b2645c8766a669c55bde1f1ef5b0518caec
Author: Michal Marek <mmarek@suse.cz>
Date:   Wed Jun 30 16:41:23 2010 +0200

    kbuild: Propagate LOCALVERSION= down to scripts/setlocalversion
    
    Variables given on the make commandline are not exported to $(shell
    ...) commands, so run the setlocalversion script in the make rule
    directly.
    
    Signed-off-by: Michal Marek <mmarek@suse.cz>

diff --git a/Makefile b/Makefile
index a86ac8c..12ab175 100644
--- a/Makefile
+++ b/Makefile
@@ -884,11 +884,9 @@ $(vmlinux-dirs): prepare scripts
 	$(Q)$(MAKE) $(build)=$@
 
 # Store (new) KERNELRELASE string in include/config/kernel.release
-localversion = $(shell $(CONFIG_SHELL) \
-	       $(srctree)/scripts/setlocalversion $(srctree))
 include/config/kernel.release: include/config/auto.conf FORCE
 	$(Q)rm -f $@
-	$(Q)echo $(KERNELVERSION)$(localversion) > $@
+	$(Q)echo "$(KERNELVERSION)$$($(CONFIG_SHELL) scripts/setlocalversion $(srctree))" > $@
 
 
 # Things we need to do before we recursively start building the kernel
--

[ message continues ]

If more stuff like this is coming, we should probably rewrite

You probably want

srctree="$1" 

to catch spaces and co. in the path.

Otherwise I just had a quick view over it, but seems to look good.

Nico

-- 
New PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
Please resign, if you signed 9885188C or 8D0E27A4.

Currently moving *.schottelius.org to http://www.nico.schottelius.org/ ...
[ message continues ]

That's the same, the value in variable assignment is not subject to word

Thanks!

/me is now wondering if it's ok to push this for 2.6.35. At least, there
were no bugreports from linux-next users so far.

Michal
--

[ message continues ]

Well, sometime you'll have to push it and I'm not sure how many
"no bugreports" you'll want to wait for :-)

Cheers,

Nico

-- 
New PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
Please resign, if you signed 9885188C or 8D0E27A4.

Currently moving *.schottelius.org to http://www.nico.schottelius.org/ ...
[ message continues ]