On Mon, Feb 07, 2022 at 11:52:12AM +0000, Jiaxun Yang wrote:
Since the SUBLEVEL overflowed LINUX_VERSION, we have no reliable way to tell the current SUBLEVEL in source code.
What in-kernel code needs to know the SUBLEVEL?
This brings significant difficulties for backport works to deal with changes in stable releases.
What backport issues?
Define those macros so we can continue to get proper SUBLEVEL in source without breaking stable ABI by refining KERNEL_VERSION bit fields.
Signed-off-by: Jiaxun Yang jiaxun.yang@flygoat.com
For some context: https://lore.kernel.org/backports/bb0ae37aa770e016463706d557fec1c5205bc6a9.c...
Makefile | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile index 99d37c23495e..8132f81d94d8 100644 --- a/Makefile +++ b/Makefile @@ -1142,7 +1142,10 @@ endef define filechk_version.h (echo #define LINUX_VERSION_CODE $(shell \ expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255); \
- echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';)
- echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'; \
- echo #define LINUX_VERSION_MAJOR $(VERSION); \
- echo #define LINUX_VERSION_PATCHLEVEL $(PATCHLEVEL); \
- echo #define LINUX_VERSION_SUBLEVEL $(SUBLEVEL);)
This is already in Makefile, are you sure you just do not need to backport a specific patch instead of making your own that does the same thing?
thanks,
greg k-h