* Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION
2021-01-18 9:21 ` Greg KH
@ 2021-01-18 9:24 ` Greg KH
2021-01-18 13:39 ` Sasha Levin
2021-01-18 10:27 ` Masahiro Yamada
2021-01-18 13:38 ` Sasha Levin
2 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2021-01-18 9:24 UTC (permalink / raw)
To: Sasha Levin
Cc: masahiroy, michal.lkml, torvalds, linux-kbuild, linux-kernel, stable
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION
2021-01-18 9:24 ` Greg KH
@ 2021-01-18 13:39 ` Sasha Levin
2021-01-18 13:52 ` Greg KH
0 siblings, 1 reply; 11+ messages in thread
From: Sasha Levin @ 2021-01-18 13:39 UTC (permalink / raw)
To: Greg KH
Cc: masahiroy, michal.lkml, torvalds, linux-kbuild, linux-kernel, stable
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION
2021-01-18 13:39 ` Sasha Levin
@ 2021-01-18 13:52 ` Greg KH
2021-01-18 15:31 ` Sasha Levin
0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2021-01-18 13:52 UTC (permalink / raw)
To: Sasha Levin
Cc: masahiroy, michal.lkml, torvalds, linux-kbuild, linux-kernel, stable
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 :)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION
2021-01-18 13:52 ` Greg KH
@ 2021-01-18 15:31 ` Sasha Levin
2021-01-18 16:39 ` Greg KH
0 siblings, 1 reply; 11+ messages in thread
From: Sasha Levin @ 2021-01-18 15:31 UTC (permalink / raw)
To: Greg KH
Cc: masahiroy, michal.lkml, torvalds, linux-kbuild, linux-kernel, stable
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION
2021-01-18 15:31 ` Sasha Levin
@ 2021-01-18 16:39 ` Greg KH
0 siblings, 0 replies; 11+ messages in thread
From: Greg KH @ 2021-01-18 16:39 UTC (permalink / raw)
To: Sasha Levin
Cc: masahiroy, michal.lkml, torvalds, linux-kbuild, linux-kernel, stable
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION
2021-01-18 9:21 ` Greg KH
2021-01-18 9:24 ` Greg KH
@ 2021-01-18 10:27 ` Masahiro Yamada
2021-01-18 10:32 ` Greg KH
2021-01-18 22:54 ` David Laight
2021-01-18 13:38 ` Sasha Levin
2 siblings, 2 replies; 11+ messages in thread
From: Masahiro Yamada @ 2021-01-18 10:27 UTC (permalink / raw)
To: Greg KH
Cc: Sasha Levin, Michal Marek, Linus Torvalds,
Linux Kbuild mailing list, Linux Kernel Mailing List, stable
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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION
2021-01-18 10:27 ` Masahiro Yamada
@ 2021-01-18 10:32 ` Greg KH
2021-01-18 22:54 ` David Laight
1 sibling, 0 replies; 11+ messages in thread
From: Greg KH @ 2021-01-18 10:32 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Sasha Levin, Michal Marek, Linus Torvalds,
Linux Kbuild mailing list, Linux Kernel Mailing List, stable
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
^ permalink raw reply [flat|nested] 11+ messages in thread* RE: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION
2021-01-18 10:27 ` Masahiro Yamada
2021-01-18 10:32 ` Greg KH
@ 2021-01-18 22:54 ` David Laight
1 sibling, 0 replies; 11+ messages in thread
From: David Laight @ 2021-01-18 22:54 UTC (permalink / raw)
To: 'Masahiro Yamada', Greg KH
Cc: Sasha Levin, Michal Marek, Linus Torvalds,
Linux Kbuild mailing list, Linux Kernel Mailing List, stable
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)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION
2021-01-18 9:21 ` Greg KH
2021-01-18 9:24 ` Greg KH
2021-01-18 10:27 ` Masahiro Yamada
@ 2021-01-18 13:38 ` Sasha Levin
2 siblings, 0 replies; 11+ messages in thread
From: Sasha Levin @ 2021-01-18 13:38 UTC (permalink / raw)
To: Greg KH
Cc: masahiroy, michal.lkml, torvalds, linux-kbuild, linux-kernel, stable
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
^ permalink raw reply [flat|nested] 11+ messages in thread