[PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION

[PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION

[Sasha Levin]

SUBLEVEL only has 8 bits of space, which means that we'll overflow it
once it reaches 256.

Few of the stable branches will imminently overflow SUBLEVEL while
there's no risk of overflowing VERSION.

Thus, give SUBLEVEL 8 more bits which will be stolen from VERSION, this
should create a better balance between the different version numbers we
use.

The downside here is that Linus will have 8 bits less to play with, but
given our current release cadence (~10 weeks), the number of Linus's
fingers & toes (20), and the current VERSION (5) we can calculate that
VERSION will overflow in just over 1,000 years, so I'm kicking this can
down the road.

Cc: stable@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 9e73f82e0d863..dc2bad7a440d8 100644
--- a/Makefile
+++ b/Makefile
@@ -1252,8 +1252,8 @@ endef
 
 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))'
+	expr $(VERSION) \* 16777216 + 0$(PATCHLEVEL) \* 65536 + 0$(SUBLEVEL)); \
+	echo '#define KERNEL_VERSION(a,b,c) (((a) << 24) + ((b) << 16) + (c))'
 endef
 
 $(version_h): FORCE
-- 
2.27.0

Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION

[Greg KH]

On Sun, Jan 17, 2021 at 08:49:51PM -0500, Sasha Levin wrote:
> SUBLEVEL only has 8 bits of space, which means that we'll overflow it
> once it reaches 256.
> 
> Few of the stable branches will imminently overflow SUBLEVEL while
> there's no risk of overflowing VERSION.
> 
> Thus, give SUBLEVEL 8 more bits which will be stolen from VERSION, this
> should create a better balance between the different version numbers we
> use.
> 
> The downside here is that Linus will have 8 bits less to play with, but
> given our current release cadence (~10 weeks), the number of Linus's
> fingers & toes (20), and the current VERSION (5) we can calculate that
> VERSION will overflow in just over 1,000 years, so I'm kicking this can
> down the road.
> 
> Cc: stable@kernel.org
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>  Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 9e73f82e0d863..dc2bad7a440d8 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1252,8 +1252,8 @@ endef
>  
>  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))'
> +	expr $(VERSION) \* 16777216 + 0$(PATCHLEVEL) \* 65536 + 0$(SUBLEVEL)); \
> +	echo '#define KERNEL_VERSION(a,b,c) (((a) << 24) + ((b) << 16) + (c))'

As much as I agree, this will break in-tree users of LINUX_VERSION_CODE
that try to suck out the version/patchlevel number of the kernel release
into their own fields.  Things like USB host controller strings, v4l
ioctl reports, scsi driver ioctls, and other places do fun bit-movements
to try to unreverse this bit packing.

So how about we just provide a "real" version/subversion/revision
#define as well, and clean up all in-kernel users, so we can get this to
work, and we can change it in the future more easily.

thanks,

greg k-h

Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION

[Greg KH]

On Mon, Jan 18, 2021 at 10:21:16AM +0100, Greg KH wrote:
> On Sun, Jan 17, 2021 at 08:49:51PM -0500, Sasha Levin wrote:
> > SUBLEVEL only has 8 bits of space, which means that we'll overflow it
> > once it reaches 256.
> > 
> > Few of the stable branches will imminently overflow SUBLEVEL while
> > there's no risk of overflowing VERSION.
> > 
> > Thus, give SUBLEVEL 8 more bits which will be stolen from VERSION, this
> > should create a better balance between the different version numbers we
> > use.
> > 
> > The downside here is that Linus will have 8 bits less to play with, but
> > given our current release cadence (~10 weeks), the number of Linus's
> > fingers & toes (20), and the current VERSION (5) we can calculate that
> > VERSION will overflow in just over 1,000 years, so I'm kicking this can
> > down the road.
> > 
> > Cc: stable@kernel.org
> > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > ---
> >  Makefile | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Makefile b/Makefile
> > index 9e73f82e0d863..dc2bad7a440d8 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1252,8 +1252,8 @@ endef
> >  
> >  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))'
> > +	expr $(VERSION) \* 16777216 + 0$(PATCHLEVEL) \* 65536 + 0$(SUBLEVEL)); \
> > +	echo '#define KERNEL_VERSION(a,b,c) (((a) << 24) + ((b) << 16) + (c))'
> 
> As much as I agree, this will break in-tree users of LINUX_VERSION_CODE
> that try to suck out the version/patchlevel number of the kernel release
> into their own fields.  Things like USB host controller strings, v4l
> ioctl reports, scsi driver ioctls, and other places do fun bit-movements
> to try to unreverse this bit packing.
> 
> So how about we just provide a "real" version/subversion/revision
> #define as well, and clean up all in-kernel users, so we can get this to
> work, and we can change it in the future more easily.

Or, I can just stop doing stable releases at .255 and then abuse the
EXTRAVERSION field to put in sub-revision values.

Or, we can just not worry about it as anyone using these really old
kernels, userspace will work just fine (the number going backwards for
these fields isn't going to break anything), it's only any crazy
out-of-tree code that will get confused if they are trying to do
different build options based on SUBLEVEL :)

thanks,

greg k-h

Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION

[Masahiro Yamada]

On Mon, Jan 18, 2021 at 6:21 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sun, Jan 17, 2021 at 08:49:51PM -0500, Sasha Levin wrote:
> > SUBLEVEL only has 8 bits of space, which means that we'll overflow it
> > once it reaches 256.
> >
> > Few of the stable branches will imminently overflow SUBLEVEL while
> > there's no risk of overflowing VERSION.
> >
> > Thus, give SUBLEVEL 8 more bits which will be stolen from VERSION, this
> > should create a better balance between the different version numbers we
> > use.
> >
> > The downside here is that Linus will have 8 bits less to play with, but
> > given our current release cadence (~10 weeks), the number of Linus's
> > fingers & toes (20), and the current VERSION (5) we can calculate that
> > VERSION will overflow in just over 1,000 years, so I'm kicking this can
> > down the road.
> >
> > Cc: stable@kernel.org
> > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > ---
> >  Makefile | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 9e73f82e0d863..dc2bad7a440d8 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1252,8 +1252,8 @@ endef
> >
> >  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))'
> > +     expr $(VERSION) \* 16777216 + 0$(PATCHLEVEL) \* 65536 + 0$(SUBLEVEL)); \
> > +     echo '#define KERNEL_VERSION(a,b,c) (((a) << 24) + ((b) << 16) + (c))'
>
> As much as I agree, this will break in-tree users of LINUX_VERSION_CODE
> that try to suck out the version/patchlevel number of the kernel release
> into their own fields.  Things like USB host controller strings, v4l
> ioctl reports, scsi driver ioctls, and other places do fun bit-movements
> to try to unreverse this bit packing.


I can see a checkpatch warning about LINUX_VERSION_CODE.

See line 4528 of scripts/checkpatch.pl


  WARN("LINUX_VERSION_CODE",
       "LINUX_VERSION_CODE should be avoided, code should be for the
version to which it is merged\n" . $herecurr);



It helps external modules to be compiled for multiple kernel versions.

#if KERNEL_VERSION_CODE < KERNEL_VERSION(5, 4, 0)
    code for the kernel versions older than 5.4.0
#endif


The upstream code does not do this.
But, LINUX_VERSION_CODE is actually used in many places...





> So how about we just provide a "real" version/subversion/revision
> #define as well, and clean up all in-kernel users, so we can get this to
> work, and we can change it in the future more easily.
>
> thanks,
>
> greg k-h



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION

[Greg KH]

On Mon, Jan 18, 2021 at 07:27:51PM +0900, Masahiro Yamada wrote:
> On Mon, Jan 18, 2021 at 6:21 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Sun, Jan 17, 2021 at 08:49:51PM -0500, Sasha Levin wrote:
> > > SUBLEVEL only has 8 bits of space, which means that we'll overflow it
> > > once it reaches 256.
> > >
> > > Few of the stable branches will imminently overflow SUBLEVEL while
> > > there's no risk of overflowing VERSION.
> > >
> > > Thus, give SUBLEVEL 8 more bits which will be stolen from VERSION, this
> > > should create a better balance between the different version numbers we
> > > use.
> > >
> > > The downside here is that Linus will have 8 bits less to play with, but
> > > given our current release cadence (~10 weeks), the number of Linus's
> > > fingers & toes (20), and the current VERSION (5) we can calculate that
> > > VERSION will overflow in just over 1,000 years, so I'm kicking this can
> > > down the road.
> > >
> > > Cc: stable@kernel.org
> > > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > > ---
> > >  Makefile | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index 9e73f82e0d863..dc2bad7a440d8 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -1252,8 +1252,8 @@ endef
> > >
> > >  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))'
> > > +     expr $(VERSION) \* 16777216 + 0$(PATCHLEVEL) \* 65536 + 0$(SUBLEVEL)); \
> > > +     echo '#define KERNEL_VERSION(a,b,c) (((a) << 24) + ((b) << 16) + (c))'
> >
> > As much as I agree, this will break in-tree users of LINUX_VERSION_CODE
> > that try to suck out the version/patchlevel number of the kernel release
> > into their own fields.  Things like USB host controller strings, v4l
> > ioctl reports, scsi driver ioctls, and other places do fun bit-movements
> > to try to unreverse this bit packing.
> 
> 
> I can see a checkpatch warning about LINUX_VERSION_CODE.
> 
> See line 4528 of scripts/checkpatch.pl
> 
> 
>   WARN("LINUX_VERSION_CODE",
>        "LINUX_VERSION_CODE should be avoided, code should be for the
> version to which it is merged\n" . $herecurr);
> 
> 
> 
> It helps external modules to be compiled for multiple kernel versions.
> 
> #if KERNEL_VERSION_CODE < KERNEL_VERSION(5, 4, 0)
>     code for the kernel versions older than 5.4.0
> #endif
> 
> 
> The upstream code does not do this.
> But, LINUX_VERSION_CODE is actually used in many places...

Yes, it is used in a number of user/kernel apis for various reasons.

And the above patch will break them :(

thanks,

greg k-h

Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION

[Sasha Levin]

On Mon, Jan 18, 2021 at 10:21:16AM +0100, Greg KH wrote:
>On Sun, Jan 17, 2021 at 08:49:51PM -0500, Sasha Levin wrote:
>> SUBLEVEL only has 8 bits of space, which means that we'll overflow it
>> once it reaches 256.
>>
>> Few of the stable branches will imminently overflow SUBLEVEL while
>> there's no risk of overflowing VERSION.
>>
>> Thus, give SUBLEVEL 8 more bits which will be stolen from VERSION, this
>> should create a better balance between the different version numbers we
>> use.
>>
>> The downside here is that Linus will have 8 bits less to play with, but
>> given our current release cadence (~10 weeks), the number of Linus's
>> fingers & toes (20), and the current VERSION (5) we can calculate that
>> VERSION will overflow in just over 1,000 years, so I'm kicking this can
>> down the road.
>>
>> Cc: stable@kernel.org
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>> ---
>>  Makefile | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 9e73f82e0d863..dc2bad7a440d8 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1252,8 +1252,8 @@ endef
>>
>>  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))'
>> +	expr $(VERSION) \* 16777216 + 0$(PATCHLEVEL) \* 65536 + 0$(SUBLEVEL)); \
>> +	echo '#define KERNEL_VERSION(a,b,c) (((a) << 24) + ((b) << 16) + (c))'
>
>As much as I agree, this will break in-tree users of LINUX_VERSION_CODE
>that try to suck out the version/patchlevel number of the kernel release
>into their own fields.  Things like USB host controller strings, v4l
>ioctl reports, scsi driver ioctls, and other places do fun bit-movements
>to try to unreverse this bit packing.
>
>So how about we just provide a "real" version/subversion/revision
>#define as well, and clean up all in-kernel users, so we can get this to
>work, and we can change it in the future more easily.

Uh, yes, I see what you mean. I'll fix those up and resend.

-- 
Thanks,
Sasha

Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION

[Sasha Levin]

On Mon, Jan 18, 2021 at 10:24:33AM +0100, Greg KH wrote:
>On Mon, Jan 18, 2021 at 10:21:16AM +0100, Greg KH wrote:
>> On Sun, Jan 17, 2021 at 08:49:51PM -0500, Sasha Levin wrote:
>> > SUBLEVEL only has 8 bits of space, which means that we'll overflow it
>> > once it reaches 256.
>> >
>> > Few of the stable branches will imminently overflow SUBLEVEL while
>> > there's no risk of overflowing VERSION.
>> >
>> > Thus, give SUBLEVEL 8 more bits which will be stolen from VERSION, this
>> > should create a better balance between the different version numbers we
>> > use.
>> >
>> > The downside here is that Linus will have 8 bits less to play with, but
>> > given our current release cadence (~10 weeks), the number of Linus's
>> > fingers & toes (20), and the current VERSION (5) we can calculate that
>> > VERSION will overflow in just over 1,000 years, so I'm kicking this can
>> > down the road.
>> >
>> > Cc: stable@kernel.org
>> > Signed-off-by: Sasha Levin <sashal@kernel.org>
>> > ---
>> >  Makefile | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/Makefile b/Makefile
>> > index 9e73f82e0d863..dc2bad7a440d8 100644
>> > --- a/Makefile
>> > +++ b/Makefile
>> > @@ -1252,8 +1252,8 @@ endef
>> >
>> >  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))'
>> > +	expr $(VERSION) \* 16777216 + 0$(PATCHLEVEL) \* 65536 + 0$(SUBLEVEL)); \
>> > +	echo '#define KERNEL_VERSION(a,b,c) (((a) << 24) + ((b) << 16) + (c))'
>>
>> As much as I agree, this will break in-tree users of LINUX_VERSION_CODE
>> that try to suck out the version/patchlevel number of the kernel release
>> into their own fields.  Things like USB host controller strings, v4l
>> ioctl reports, scsi driver ioctls, and other places do fun bit-movements
>> to try to unreverse this bit packing.
>>
>> So how about we just provide a "real" version/subversion/revision
>> #define as well, and clean up all in-kernel users, so we can get this to
>> work, and we can change it in the future more easily.
>
>Or, I can just stop doing stable releases at .255 and then abuse the
>EXTRAVERSION field to put in sub-revision values.
>
>Or, we can just not worry about it as anyone using these really old
>kernels, userspace will work just fine (the number going backwards for
>these fields isn't going to break anything), it's only any crazy
>out-of-tree code that will get confused if they are trying to do
>different build options based on SUBLEVEL :)

I think it would also affect code that doesn't do things based on
SBULEVEL. Consider something like:

	if (LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0))

Which will cause 4.4.256 to now change the result of that comparison.

-- 
Thanks,
Sasha

Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION

[Greg KH]

On Mon, Jan 18, 2021 at 08:39:59AM -0500, Sasha Levin wrote:
> On Mon, Jan 18, 2021 at 10:24:33AM +0100, Greg KH wrote:
> > On Mon, Jan 18, 2021 at 10:21:16AM +0100, Greg KH wrote:
> > > On Sun, Jan 17, 2021 at 08:49:51PM -0500, Sasha Levin wrote:
> > > > SUBLEVEL only has 8 bits of space, which means that we'll overflow it
> > > > once it reaches 256.
> > > >
> > > > Few of the stable branches will imminently overflow SUBLEVEL while
> > > > there's no risk of overflowing VERSION.
> > > >
> > > > Thus, give SUBLEVEL 8 more bits which will be stolen from VERSION, this
> > > > should create a better balance between the different version numbers we
> > > > use.
> > > >
> > > > The downside here is that Linus will have 8 bits less to play with, but
> > > > given our current release cadence (~10 weeks), the number of Linus's
> > > > fingers & toes (20), and the current VERSION (5) we can calculate that
> > > > VERSION will overflow in just over 1,000 years, so I'm kicking this can
> > > > down the road.
> > > >
> > > > Cc: stable@kernel.org
> > > > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > > > ---
> > > >  Makefile | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/Makefile b/Makefile
> > > > index 9e73f82e0d863..dc2bad7a440d8 100644
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -1252,8 +1252,8 @@ endef
> > > >
> > > >  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))'
> > > > +	expr $(VERSION) \* 16777216 + 0$(PATCHLEVEL) \* 65536 + 0$(SUBLEVEL)); \
> > > > +	echo '#define KERNEL_VERSION(a,b,c) (((a) << 24) + ((b) << 16) + (c))'
> > > 
> > > As much as I agree, this will break in-tree users of LINUX_VERSION_CODE
> > > that try to suck out the version/patchlevel number of the kernel release
> > > into their own fields.  Things like USB host controller strings, v4l
> > > ioctl reports, scsi driver ioctls, and other places do fun bit-movements
> > > to try to unreverse this bit packing.
> > > 
> > > So how about we just provide a "real" version/subversion/revision
> > > #define as well, and clean up all in-kernel users, so we can get this to
> > > work, and we can change it in the future more easily.
> > 
> > Or, I can just stop doing stable releases at .255 and then abuse the
> > EXTRAVERSION field to put in sub-revision values.
> > 
> > Or, we can just not worry about it as anyone using these really old
> > kernels, userspace will work just fine (the number going backwards for
> > these fields isn't going to break anything), it's only any crazy
> > out-of-tree code that will get confused if they are trying to do
> > different build options based on SUBLEVEL :)
> 
> I think it would also affect code that doesn't do things based on
> SBULEVEL. Consider something like:
> 
> 	if (LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0))
> 
> Which will cause 4.4.256 to now change the result of that comparison.

Sure, but there are no in-kernel users like this, so my sympathy is
quite low :)

Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION

[Sasha Levin]

On Mon, Jan 18, 2021 at 02:52:02PM +0100, Greg KH wrote:
>On Mon, Jan 18, 2021 at 08:39:59AM -0500, Sasha Levin wrote:
>> I think it would also affect code that doesn't do things based on
>> SBULEVEL. Consider something like:
>>
>> 	if (LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0))
>>
>> Which will cause 4.4.256 to now change the result of that comparison.
>
>Sure, but there are no in-kernel users like this, so my sympathy is
>quite low :)

Wouldn't it be an issue for the hacky in-kernel users too? For example,
right now the USB code does:

	#define KERNEL_REL      bin2bcd(((LINUX_VERSION_CODE >> 16) & 0x0ff))
	#define KERNEL_VER      bin2bcd(((LINUX_VERSION_CODE >> 8) & 0x0ff))

After 4.4.256, KERNEL_VER will be (5) rather than (4), indicating a
version of 4.5.

-- 
Thanks,
Sasha

Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION

[Greg KH]

On Mon, Jan 18, 2021 at 10:31:35AM -0500, Sasha Levin wrote:
> On Mon, Jan 18, 2021 at 02:52:02PM +0100, Greg KH wrote:
> > On Mon, Jan 18, 2021 at 08:39:59AM -0500, Sasha Levin wrote:
> > > I think it would also affect code that doesn't do things based on
> > > SBULEVEL. Consider something like:
> > > 
> > > 	if (LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0))
> > > 
> > > Which will cause 4.4.256 to now change the result of that comparison.
> > 
> > Sure, but there are no in-kernel users like this, so my sympathy is
> > quite low :)
> 
> Wouldn't it be an issue for the hacky in-kernel users too? For example,
> right now the USB code does:
> 
> 	#define KERNEL_REL      bin2bcd(((LINUX_VERSION_CODE >> 16) & 0x0ff))
> 	#define KERNEL_VER      bin2bcd(((LINUX_VERSION_CODE >> 8) & 0x0ff))
> 
> After 4.4.256, KERNEL_VER will be (5) rather than (4), indicating a
> version of 4.5.

Which, really, is just fine.  This is an informational string that shows
up in 'lsusb' for root hubs.  Same for V4L devices, they just want to
send some string to userspace.  Yes, it might look odd, but nothing is
going to break, it's just a string :)

thanks,

greg k-h

RE: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION

[David Laight]

From: Masahiro Yamada
> Sent: 18 January 2021 10:28
...
> It helps external modules to be compiled for multiple kernel versions.
> 
> #if KERNEL_VERSION_CODE < KERNEL_VERSION(5, 4, 0)
>     code for the kernel versions older than 5.4.0
> #endif

I've just done a scan through some drivers.
The only checks with a non-zero sub-rev are for 2.6.nnn.
So provided KERNEL_VERSION_CODE is changed to match
nothing of ours breaks.

I've only found tests for the following:
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 28)
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 32)
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34)
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 36)
#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 18, 0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 11, 0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 13, 0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 17, 0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 18, 0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 0, 0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 7, 0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 8, 0)

Although some seem to be against VERSION_CODE()
rather than KERNEL_VERSION().

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)