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
next 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.