Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[PATCH 2/2] Makefile: "make kernelrelease" should show the correct full kernel version

505 views
Skip to first unread message

Amerigo Wang

unread,
Jun 27, 2010, 11:10:02 PM6/27/10
to
From: Amerigo Wang <amw...@redhat.com>
Date: Mon, 28 Jun 2010 10:45:21 +0800

After commit 85a256d8e0116c8f5ad276730830f5d4d473344d, 'make kernelrelease' doesn't
show the correct full kernel version. This patch fixes it, 'make kernelrelease' will
show the same version name with the one you finally get.

Cc: David Rientjes <rien...@google.com>
Cc: Michal Marek <mma...@suse.cz>
Signed-off-by: Amerigo Wang <amw...@redhat.com>
---
Makefile | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 710f91c..2b517a1 100644
--- a/Makefile
+++ b/Makefile
@@ -414,7 +414,7 @@ endif
no-dot-config-targets := clean mrproper distclean \
cscope TAGS tags help %docs check% \
include/linux/version.h headers_% \
- kernelrelease kernelversion
+ kernelversion

config-targets := 0
mixed-targets := 0
@@ -1468,8 +1468,7 @@ checkstack:
$(PERL) $(src)/scripts/checkstack.pl $(CHECKSTACK_ARCH)

kernelrelease:
- $(if $(wildcard include/config/kernel.release), $(Q)echo $(KERNELRELEASE), \
- $(error kernelrelease not valid - run 'make prepare' to update it))
+ @echo $(kernelrelease)
kernelversion:
@echo $(KERNELVERSION)

--
1.6.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Michal Marek

unread,
Jun 29, 2010, 8:20:02 AM6/29/10
to
On Tue, Jun 29, 2010 at 02:13:15PM +0200, Michal Marek wrote:
> AFAICS it was broken even before 85a256d. Nevertheless, the patch is
> correct, but conflicts with 0915512 in the kbuild tree.

http://git.kernel.org/?p=linux/kernel/git/mmarek/kbuild-2.6.git;a=commitdiff;h=0915512 . It is also in linux-next.

Michal

Michal Marek

unread,
Jun 29, 2010, 8:20:02 AM6/29/10
to

AFAICS it was broken even before 85a256d. Nevertheless, the patch is
correct, but conflicts with 0915512 in the kbuild tree. What about this
one?

From 01ab17887f4cdcb8bb5a5d1bc3b160d186e6e99b Mon Sep 17 00:00:00 2001


From: Amerigo Wang <amw...@redhat.com>
Date: Mon, 28 Jun 2010 10:45:21 +0800

Subject: [PATCH] Makefile: "make kernelrelease" should show the correct full kernel version

After commit 85a256d8e0116c8f5ad276730830f5d4d473344d, 'make kernelrelease'
doesn't show the correct full kernel version. This patch fixes it,
'make kernelrelease' will show the same version name with the one
you finally get.

Cc: David Rientjes <rien...@google.com>
Cc: Michal Marek <mma...@suse.cz>
Signed-off-by: Amerigo Wang <amw...@redhat.com>

[mmarek: merged with 0915512 and added dependency on
include/config/kernel.release]
Signed-off-by: Michal Marek <mma...@suse.cz>

diff --git a/Makefile b/Makefile
index a86ac8c..dceb4f1 100644


--- a/Makefile
+++ b/Makefile
@@ -414,7 +414,7 @@ endif
no-dot-config-targets := clean mrproper distclean \
cscope TAGS tags help %docs check% \
include/linux/version.h headers_% \
- kernelrelease kernelversion
+ kernelversion

config-targets := 0
mixed-targets := 0

@@ -1395,9 +1395,9 @@ checkstack:
$(OBJDUMP) -d vmlinux $$(find . -name '*.ko') | \
$(PERL) $(src)/scripts/checkstack.pl $(CHECKSTACK_ARCH)

-kernelrelease:


- $(if $(wildcard include/config/kernel.release), $(Q)echo $(KERNELRELEASE), \
- $(error kernelrelease not valid - run 'make prepare' to update it))

+kernelrelease: include/config/kernel.release
+ @echo $(KERNELRELEASE)
+
kernelversion:
@echo $(KERNELVERSION)

Cong Wang

unread,
Jun 30, 2010, 6:40:01 AM6/30/10
to

Hmm, I am not sure. IIRC, my first try was also using KERNELRELEASE but it
didn't work. Note, I may remember wrongly. :)

Have you tested it? Sorry that currently I don't have time to test it, I am
quite busy with other stuffs...

Thanks!

Brice Goglin

unread,
Aug 18, 2010, 3:30:02 AM8/18/10
to
This patch (actually 01ab17887 in 2.6.36-rc1) reveals what looks like a
problem to me: make kernelrelease always regenerates
include/config/kernel.release even if it's already more recent than
include/config/auto.conf. Is this the expected behavior? Do we really
need include/config/kernel.release to depend on FORCE?

$ make kernelrelease -d
[...]
Considering target file `kernelrelease'.
File `kernelrelease' does not exist.
Considering target file `include/config/kernel.release'.
Pruning file `include/config/auto.conf'.
Considering target file `FORCE'.
File `FORCE' does not exist.
Finished prerequisites of target file `FORCE'.
Must remake target `FORCE'.
Successfully remade target file `FORCE'.
Finished prerequisites of target file `include/config/kernel.release'.
Prerequisite `include/config/auto.conf' is older than target `include/config/kernel.release'.
Prerequisite `FORCE' of target `include/config/kernel.release' does not exist.
Must remake target `include/config/kernel.release'.


Thanks,
Brice

--

Cong Wang

unread,
Aug 18, 2010, 4:10:02 AM8/18/10
to
On 08/18/10 15:15, Brice Goglin wrote:
> This patch (actually 01ab17887 in 2.6.36-rc1) reveals what looks like a
> problem to me: make kernelrelease always regenerates
> include/config/kernel.release even if it's already more recent than
> include/config/auto.conf. Is this the expected behavior? Do we really
> need include/config/kernel.release to depend on FORCE?
>

I think so, because "LOCALVERSION=" can be given from command line,
so we need to regenerate it.

Or am I missing your point here?

--
The opposite of love is not hate, it's indifference.
- Elie Wiesel

Brice Goglin

unread,
Aug 18, 2010, 4:50:02 AM8/18/10
to
Le 18/08/2010 10:10, Cong Wang a écrit :
> On 08/18/10 15:15, Brice Goglin wrote:
>> This patch (actually 01ab17887 in 2.6.36-rc1) reveals what looks like a
>> problem to me: make kernelrelease always regenerates
>> include/config/kernel.release even if it's already more recent than
>> include/config/auto.conf. Is this the expected behavior? Do we really
>> need include/config/kernel.release to depend on FORCE?
>>
>
> I think so, because "LOCALVERSION=" can be given from command line,
> so we need to regenerate it.
>
> Or am I missing your point here?
>

Interesting. I assumed "make kernelrelease" was mainly here to display
the release string (which means you would not need write access to the
kernel build dir). And indeed make help says:
kernelrelease - Output the release version string
Right now, it looks like "update the version string and by the way
display it too" (and you need write access).

Brice

Cong Wang

unread,
Aug 18, 2010, 5:00:02 AM8/18/10
to
On 08/18/10 16:38, Brice Goglin wrote:
> Le 18/08/2010 10:10, Cong Wang a écrit :
>> On 08/18/10 15:15, Brice Goglin wrote:
>>> This patch (actually 01ab17887 in 2.6.36-rc1) reveals what looks like a
>>> problem to me: make kernelrelease always regenerates
>>> include/config/kernel.release even if it's already more recent than
>>> include/config/auto.conf. Is this the expected behavior? Do we really
>>> need include/config/kernel.release to depend on FORCE?
>>>
>>
>> I think so, because "LOCALVERSION=" can be given from command line,
>> so we need to regenerate it.
>>
>> Or am I missing your point here?
>>
>
> Interesting. I assumed "make kernelrelease" was mainly here to display
> the release string (which means you would not need write access to the
> kernel build dir). And indeed make help says:
> kernelrelease - Output the release version string
> Right now, it looks like "update the version string and by the way
> display it too" (and you need write access).
>

I believe you will also need write access even without this patch,
if you compile a fresh kernel. So your assumption is not correct.

--
The opposite of love is not hate, it's indifference.
- Elie Wiesel

Brice Goglin

unread,
Aug 18, 2010, 5:00:02 AM8/18/10
to
Le 18/08/2010 10:57, Cong Wang a écrit :
> On 08/18/10 16:38, Brice Goglin wrote:
>> Le 18/08/2010 10:10, Cong Wang a écrit :
>>> On 08/18/10 15:15, Brice Goglin wrote:
>>>> This patch (actually 01ab17887 in 2.6.36-rc1) reveals what looks
>>>> like a
>>>> problem to me: make kernelrelease always regenerates
>>>> include/config/kernel.release even if it's already more recent than
>>>> include/config/auto.conf. Is this the expected behavior? Do we really
>>>> need include/config/kernel.release to depend on FORCE?
>>>>
>>>
>>> I think so, because "LOCALVERSION=" can be given from command line,
>>> so we need to regenerate it.
>>>
>>> Or am I missing your point here?
>>>
>>
>> Interesting. I assumed "make kernelrelease" was mainly here to display
>> the release string (which means you would not need write access to the
>> kernel build dir). And indeed make help says:
>> kernelrelease - Output the release version string
>> Right now, it looks like "update the version string and by the way
>> display it too" (and you need write access).
>>
>
> I believe you will also need write access even without this patch,
> if you compile a fresh kernel. So your assumption is not correct.
>

If I revert 01ab17887f4, I don't need write access. Things always worked
fine before 2.6.36 as far I remember.

Brice

Cong Wang

unread,
Aug 18, 2010, 5:20:02 AM8/18/10
to
On 08/18/10 16:52, Brice Goglin wrote:
> Le 18/08/2010 10:57, Cong Wang a écrit :
>> On 08/18/10 16:38, Brice Goglin wrote:
>>> Le 18/08/2010 10:10, Cong Wang a écrit :
>>>> On 08/18/10 15:15, Brice Goglin wrote:
>>>>> This patch (actually 01ab17887 in 2.6.36-rc1) reveals what looks
>>>>> like a
>>>>> problem to me: make kernelrelease always regenerates
>>>>> include/config/kernel.release even if it's already more recent than
>>>>> include/config/auto.conf. Is this the expected behavior? Do we really
>>>>> need include/config/kernel.release to depend on FORCE?
>>>>>
>>>>
>>>> I think so, because "LOCALVERSION=" can be given from command line,
>>>> so we need to regenerate it.
>>>>
>>>> Or am I missing your point here?
>>>>
>>>
>>> Interesting. I assumed "make kernelrelease" was mainly here to display
>>> the release string (which means you would not need write access to the
>>> kernel build dir). And indeed make help says:
>>> kernelrelease - Output the release version string
>>> Right now, it looks like "update the version string and by the way
>>> display it too" (and you need write access).
>>>
>>
>> I believe you will also need write access even without this patch,
>> if you compile a fresh kernel. So your assumption is not correct.
>>
>
> If I revert 01ab17887f4, I don't need write access. Things always worked
> fine before 2.6.36 as far I remember.
>

Ah, I forgot Michal checked in a slightly different patch with mine. :)

Does the attached patch work for you?


---
Signed-off-by: WANG Cong <amw...@redhat.com>

makefile-not-regenerate-release.diff

Brice Goglin

unread,
Aug 18, 2010, 5:30:02 AM8/18/10
to
Le 18/08/2010 11:20, Cong Wang a écrit :
> diff --git a/Makefile b/Makefile
> index f3bdff8..25da252 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1408,8 +1408,8 @@ checkstack:

> $(OBJDUMP) -d vmlinux $$(find . -name '*.ko') | \
> $(PERL) $(src)/scripts/checkstack.pl $(CHECKSTACK_ARCH)
>
> -kernelrelease: include/config/kernel.release
> - @echo $(KERNELRELEASE)
> +kernelrelease:
> + @echo "$(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion $(srctree))"
>
> kernelversion:
> @echo $(KERNELVERSION)
>

It works, thanks!

Tested-by: Brice Goglin <Brice....@inria.fr>

0 new messages