| Message ID | 20210118014951.250815-1-sashal@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | kbuild: give SUBLEVEL more room in KERNEL_VERSION | expand |
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
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
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
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
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.
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.
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 :)
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.
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
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)
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
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(-)