[PATCH] Makefile: version.h macros KERNEL_EXTRAVERSION, LINUX_EXTRAVERSION_CODE

[PATCH] Makefile: version.h macros KERNEL_EXTRAVERSION, LINUX_EXTRAVERSION_CODE

[Kamal Mostafa]

Adds new macro KERNEL_EXTRAVERSION(a,b,c,d) and value
LINUX_EXTRAVERSION_CODE to version.h, allowing ranged version checks of
extended-stable versions that use a numeric EXTRAVERSION value.

The new KERNEL_EXTRAVERSION(a,b,c,d) works like KERNEL_VERSION(a,b,c)...
If EXTRAVERSION is set to ".{integer}" (the common extended-stable kernel
version number scheme) then {integer} corresponds to KERNEL_EXTRAVERSION's
fourth arg.  If EXTRAVERSION is blank or a non-".{integer}" string like
"-rc5", that corresponds to a fourth parameter of 0.

Example usage:

  #if ( LINUX_EXTRAVERSION_CODE >= KERNEL_EXTRAVERSION(3,13,11,5) )
      // compiles for (3.13.11 with "EXTRAVERSION = .5") or greater value
  #endif

Cc: stable@vger.kernel.org
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
---
 Makefile | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 97b2861..e579628 100644
--- a/Makefile
+++ b/Makefile
@@ -953,10 +953,15 @@ define filechk_utsrelease.h
 	(echo \#define UTS_RELEASE \"$(KERNELRELEASE)\";)
 endef
 
+extraversionnum := $(shell \
+	echo "$(EXTRAVERSION)" | sed -n '/\.\([0-9]*\).*/s//\1/p')
 define filechk_version.h
 	(echo \#define LINUX_VERSION_CODE $(shell                         \
 	expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
-	echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';)
+	echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'; \
+	echo \#define LINUX_EXTRAVERSION_CODE $(shell                      \
+	expr $(VERSION) \* 268435456 + 0$(PATCHLEVEL) \* 1048576 + 0$(SUBLEVEL) \* 4096 + 0$(extraversionnum)); \
+	echo '#define KERNEL_EXTRAVERSION(a,b,c,d) (((a)<<28) + ((b)<<20) + ((c)<<12) + (d))';)
 endef
 
 $(version_h): $(srctree)/Makefile FORCE
-- 
1.9.1

Re: [PATCH] Makefile: version.h macros KERNEL_EXTRAVERSION, LINUX_EXTRAVERSION_CODE

[Michal Marek]

Dne 19.6.2014 16:44, Kamal Mostafa napsal(a):
> Adds new macro KERNEL_EXTRAVERSION(a,b,c,d) and value
> LINUX_EXTRAVERSION_CODE to version.h, allowing ranged version checks of
> extended-stable versions that use a numeric EXTRAVERSION value.
> 
> The new KERNEL_EXTRAVERSION(a,b,c,d) works like KERNEL_VERSION(a,b,c)...
> If EXTRAVERSION is set to ".{integer}" (the common extended-stable kernel
> version number scheme) then {integer} corresponds to KERNEL_EXTRAVERSION's
> fourth arg.  If EXTRAVERSION is blank or a non-".{integer}" string like
> "-rc5", that corresponds to a fourth parameter of 0.

Why don't you guys simply increment the third digit in the extended
stable tree and get support for KERNEL_VERSION() for free? You always
start after the respective stable branch has reached EOL, don't you?

Thanks,
Michal

Re: [PATCH] Makefile: version.h macros KERNEL_EXTRAVERSION, LINUX_EXTRAVERSION_CODE

[Kamal Mostafa]

On Fri, 2014-06-20 at 11:39 +0200, Michal Marek wrote:
> Dne 19.6.2014 16:44, Kamal Mostafa napsal(a):
> > Adds new macro KERNEL_EXTRAVERSION(a,b,c,d) and value
> > LINUX_EXTRAVERSION_CODE to version.h, allowing ranged version checks of
> > extended-stable versions that use a numeric EXTRAVERSION value.
> > 
> > The new KERNEL_EXTRAVERSION(a,b,c,d) works like KERNEL_VERSION(a,b,c)...
> > If EXTRAVERSION is set to ".{integer}" (the common extended-stable kernel
> > version number scheme) then {integer} corresponds to KERNEL_EXTRAVERSION's
> > fourth arg.  If EXTRAVERSION is blank or a non-".{integer}" string like
> > "-rc5", that corresponds to a fourth parameter of 0.
> 
> Why don't you guys simply increment the third digit in the extended
> stable tree and get support for KERNEL_VERSION() for free? You always
> start after the respective stable branch has reached EOL, don't you?

Yes, we only start after the stable branch has reached EOL.

We don't increment the third integer for the extended-stable branches
(we add a fourth integer instead) in order to avoid the possibility of a
collision if Greg KH were to ever release a "special" post-EOL version
of one of his branches.

 -Kamal

Re: [PATCH] Makefile: version.h macros KERNEL_EXTRAVERSION, LINUX_EXTRAVERSION_CODE

[Michal Marek]

Dne 20.6.2014 17:47, Kamal Mostafa napsal(a):
> On Fri, 2014-06-20 at 11:39 +0200, Michal Marek wrote:
>> Why don't you guys simply increment the third digit in the extended
>> stable tree and get support for KERNEL_VERSION() for free? You always
>> start after the respective stable branch has reached EOL, don't you?
> 
> Yes, we only start after the stable branch has reached EOL.
> 
> We don't increment the third integer for the extended-stable branches
> (we add a fourth integer instead) in order to avoid the possibility of a
> collision if Greg KH were to ever release a "special" post-EOL version
> of one of his branches.

The maintainers of 2.6.32.y, 3.2.y and 3.12.y have taken that risk and
it has been working fine so far ;-).

Michal

Re: [PATCH] Makefile: version.h macros KERNEL_EXTRAVERSION, LINUX_EXTRAVERSION_CODE

[Greg KH]

On Fri, Jun 20, 2014 at 10:34:03PM +0200, Michal Marek wrote:
> Dne 20.6.2014 17:47, Kamal Mostafa napsal(a):
> > On Fri, 2014-06-20 at 11:39 +0200, Michal Marek wrote:
> >> Why don't you guys simply increment the third digit in the extended
> >> stable tree and get support for KERNEL_VERSION() for free? You always
> >> start after the respective stable branch has reached EOL, don't you?
> > 
> > Yes, we only start after the stable branch has reached EOL.
> > 
> > We don't increment the third integer for the extended-stable branches
> > (we add a fourth integer instead) in order to avoid the possibility of a
> > collision if Greg KH were to ever release a "special" post-EOL version
> > of one of his branches.
> 
> The maintainers of 2.6.32.y, 3.2.y and 3.12.y have taken that risk and
> it has been working fine so far ;-).

Those maintainers are doing so on the kernel.org infrastructure, with my
help and encouragement, unlike these Canonical "stable" trees, so their
risk was a lot less :)

thanks,

greg k-h