All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: masahiroy@kernel.org, michal.lkml@markovi.net,
	torvalds@linux-foundation.org
Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
	gregkh@linuxfoundation.org, Sasha Levin <sashal@kernel.org>,
	stable@kernel.org
Subject: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION
Date: Sun, 17 Jan 2021 20:49:51 -0500	[thread overview]
Message-ID: <20210118014951.250815-1-sashal@kernel.org> (raw)

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


             reply	other threads:[~2021-01-18  1:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-18  1:49 Sasha Levin [this message]
2021-01-18  9:21 ` [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION Greg KH
2021-01-18  9:24   ` Greg KH
2021-01-18 13:39     ` Sasha Levin
2021-01-18 13:52       ` Greg KH
2021-01-18 15:31         ` Sasha Levin
2021-01-18 16:39           ` 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210118014951.250815-1-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=stable@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.