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))' endef $(version_h): FORCE -- 2.27.0