Hi, With the following commit running "make modules_install install" over sshfs (and I suppose nfs) is extremely painful: commit fb994ecc2b1c214951366c2ba5d8b121f0010d1f Author: Greg Thelen <email@example.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 <firstname.lastname@example.org> Acked-by: David Rientjes <email@example.com> Signed-off-by: Michal Marek <firstname.lastname@example.org> 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 --
... 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 --
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 <email@example.com> Cc: David Rientjes <firstname.lastname@example.org> Cc: Greg Thelen <email@example.com> Cc: Nico Schottelius <firstname.lastname@example.org> Signed-off-by: Michal Marek <email@example.com> --- 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 ...
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. --
No, I am sorry, it is not .36 material as the building on remote box was messed up in .35 cycle. -- Dmitry --
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 --
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 --
I now found that my patch breaks 'make LOCALVERSION=... '. The following patch should fix it. Michal commit 0a564b2645c8766a669c55bde1f1ef5b0518caec Author: Michal Marek <firstname.lastname@example.org> 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 <email@example.com> 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 --
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/ ...
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 --
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/ ...
|Greg KH||Og dreams of kernels|
|Jens Axboe||[PATCH 31/33] Fusion: sg chaining support|
|Arnd Bergmann||Re: finding your own dead "CONFIG_" variables|
|Mark Brown||[PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset|
|Tony Breeds||[LGUEST] Look in object dir for .config|
|Brian Downing||Re: Git in a Nutshell guide|
|John Benes||Re: master has some toys|
|Matthias Lederhofer||[PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree|
|Alexander Sulfrian||[RFC/PATCH] RE: git calls SSH_ASKPASS even if DISPLAY is not set|
|Junio C Hamano||Re: Rss produced by git is not valid xml?|