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@xxxxxxxxxx
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
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
