I'm announcing the release of the 4.4.256 kernel.
This, and the 4.9.256 release are a little bit "different" than normal.
This contains only 1 patch, just the version bump from .255 to .256 which ends up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently than normal due to the "overflow".
With this release, KERNEL_VERSION(4, 4, 256) is the same as KERNEL_VERSION(4, 5, 0).
Nothing in the kernel build itself breaks with this change, but given that this is a userspace visible change, and some crazy tools (like glibc and gcc) have logic that checks the kernel version for different reasons, I wanted to do this release as an "empty" release to ensure that everything still works properly.
So, this is a YOU MUST UPGRADE requirement of a release. If you rely on the 4.4.y kernel, please throw this release into your test builds and rebuild the world and let us know if anything breaks, or if all is well.
Go forth and do full system rebuilds! Yocto and Gentoo are great for this, as will systems that use buildroot.
I'll try to hold off on doing a "real" 4.4.y release for a week to give everyone a chance to test this out and get back to me. The pending patches in the 4.4.y queue are pretty serious, so I am loath to wait longer than that, consider yourself warned...
The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git%3Ba=summa...
thanks,
greg k-h
------------
Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Greg Kroah-Hartman (1): Linux 4.4.256
diff --git a/Makefile b/Makefile index b18b61e540e9..0057587d2cbe 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,6 @@ VERSION = 4 PATCHLEVEL = 4 -SUBLEVEL = 255 +SUBLEVEL = 256 EXTRAVERSION = NAME = Blurry Fish Butt
On Fri, Feb 05, 2021 at 03:26:36PM +0100, Greg Kroah-Hartman wrote:
I'm announcing the release of the 4.4.256 kernel.
This, and the 4.9.256 release are a little bit "different" than normal.
This contains only 1 patch, just the version bump from .255 to .256 which ends up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently than normal due to the "overflow".
With this release, KERNEL_VERSION(4, 4, 256) is the same as KERNEL_VERSION(4, 5, 0).
Nothing in the kernel build itself breaks with this change, but given that this is a userspace visible change, and some crazy tools (like glibc and gcc) have logic that checks the kernel version for different reasons, I wanted to do this release as an "empty" release to ensure that everything still works properly.
So, this is a YOU MUST UPGRADE requirement of a release. If you rely on the 4.4.y kernel, please throw this release into your test builds and rebuild the world and let us know if anything breaks, or if all is well.
Go forth and do full system rebuilds! Yocto and Gentoo are great for this, as will systems that use buildroot.
I'll try to hold off on doing a "real" 4.4.y release for a week to give everyone a chance to test this out and get back to me. The pending patches in the 4.4.y queue are pretty serious, so I am loath to wait longer than that, consider yourself warned...
Thanks a lot for the heads-up. For chromeos-4.4, the version number wrap is indeed fatal: Unfortunately we have lots of vendor code in the tree which uses KERNEL_VERSION(), and all the version comparisons against KERNEL_VERSION(4,5,0) do result in compile errors.
The best workaround/hack/kludge to address the problem seems to be the idea to use 4.4.255 as version number for LINUX_VERSION_CODE and KERNEL_VERSION() if SUBLEVEL is larger than 255. Did anyone find a better solution for the problem ?
Thanks, Guenter
On Fri, Feb 05, 2021 at 12:56:58PM -0800, Guenter Roeck wrote:
On Fri, Feb 05, 2021 at 03:26:36PM +0100, Greg Kroah-Hartman wrote:
I'm announcing the release of the 4.4.256 kernel.
This, and the 4.9.256 release are a little bit "different" than normal.
This contains only 1 patch, just the version bump from .255 to .256 which ends up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently than normal due to the "overflow".
With this release, KERNEL_VERSION(4, 4, 256) is the same as KERNEL_VERSION(4, 5, 0).
Nothing in the kernel build itself breaks with this change, but given that this is a userspace visible change, and some crazy tools (like glibc and gcc) have logic that checks the kernel version for different reasons, I wanted to do this release as an "empty" release to ensure that everything still works properly.
So, this is a YOU MUST UPGRADE requirement of a release. If you rely on the 4.4.y kernel, please throw this release into your test builds and rebuild the world and let us know if anything breaks, or if all is well.
Go forth and do full system rebuilds! Yocto and Gentoo are great for this, as will systems that use buildroot.
I'll try to hold off on doing a "real" 4.4.y release for a week to give everyone a chance to test this out and get back to me. The pending patches in the 4.4.y queue are pretty serious, so I am loath to wait longer than that, consider yourself warned...
Thanks a lot for the heads-up. For chromeos-4.4, the version number wrap is indeed fatal: Unfortunately we have lots of vendor code in the tree which uses KERNEL_VERSION(), and all the version comparisons against KERNEL_VERSION(4,5,0) do result in compile errors.
The best workaround/hack/kludge to address the problem seems to be the idea to use 4.4.255 as version number for LINUX_VERSION_CODE and KERNEL_VERSION() if SUBLEVEL is larger than 255. Did anyone find a better solution for the problem ?
I think Sasha's patch here: https://lore.kernel.org/r/20210205174702.1904681-1-sashal@kernel.org is looking like the solution.
thanks,
greg k-h
On Sat, Feb 06, 2021 at 02:00:27PM +0100, Greg Kroah-Hartman wrote:
I think Sasha's patch here: https://lore.kernel.org/r/20210205174702.1904681-1-sashal@kernel.org is looking like the solution.
It might cause trouble to those forcing SUBLEVEL to a given version such as .0 to avoid exposing the exact stable version. I guess we should instead try to integrate a test on the value itself and cap it at 255.
Something like this looks more robust to me, it will use SUBLEVEL for values 0 to 255 and 255 for any larger value:
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \ + expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL <= 255)); \
Willy
On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
On Sat, Feb 06, 2021 at 02:00:27PM +0100, Greg Kroah-Hartman wrote:
I think Sasha's patch here: https://lore.kernel.org/r/20210205174702.1904681-1-sashal@kernel.org is looking like the solution.
It might cause trouble to those forcing SUBLEVEL to a given version such as .0 to avoid exposing the exact stable version. I guess we should instead try to integrate a test on the value itself and cap it at 255.
That's the main goal of the upstream submission that checks the value before capping it: https://lore.kernel.org/r/20210206035033.2036180-2-sashal@kernel.org
Something like this looks more robust to me, it will use SUBLEVEL for values 0 to 255 and 255 for any larger value:
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL <= 255)); \
I think you just rewrote the above linked patch :)
thanks,
greg k-h
On Sat, Feb 06, 2021 at 02:19:57PM +0100, Greg Kroah-Hartman wrote:
On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
On Sat, Feb 06, 2021 at 02:00:27PM +0100, Greg Kroah-Hartman wrote:
I think Sasha's patch here: https://lore.kernel.org/r/20210205174702.1904681-1-sashal@kernel.org is looking like the solution.
It might cause trouble to those forcing SUBLEVEL to a given version such as .0 to avoid exposing the exact stable version. I guess we should instead try to integrate a test on the value itself and cap it at 255.
That's the main goal of the upstream submission that checks the value before capping it: https://lore.kernel.org/r/20210206035033.2036180-2-sashal@kernel.org
Something like this looks more robust to me, it will use SUBLEVEL for values 0 to 255 and 255 for any larger value:
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL <= 255)); \
I think you just rewrote the above linked patch :)
Ah I missed it, indeed! Sorry for the noise :-)
Willy
On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
Something like this looks more robust to me, it will use SUBLEVEL for values 0 to 255 and 255 for any larger value:
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL <= 255)); \
Bah, I obviously missed a backslash above and forgot spaces around parens. Here's a tested version:
diff --git a/Makefile b/Makefile index 7d86ad6ad36c..9b91b8815b40 100644 --- a/Makefile +++ b/Makefile @@ -1252,7 +1252,7 @@ endef
define filechk_version.h echo #define LINUX_VERSION_CODE $(shell \ - expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \ + expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * ( 0$(SUBLEVEL) > 255 ) + 0$(SUBLEVEL) * ( 0$(SUBLEVEL) <= 255 ) ); \ echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))' endef
Willy
On 2/6/21 5:22 AM, Willy Tarreau wrote:
On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
Something like this looks more robust to me, it will use SUBLEVEL for values 0 to 255 and 255 for any larger value:
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL <= 255)); \
Bah, I obviously missed a backslash above and forgot spaces around parens. Here's a tested version:
diff --git a/Makefile b/Makefile index 7d86ad6ad36c..9b91b8815b40 100644 --- a/Makefile +++ b/Makefile @@ -1252,7 +1252,7 @@ endef define filechk_version.h echo #define LINUX_VERSION_CODE $(shell \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * ( 0$(SUBLEVEL) > 255 ) + 0$(SUBLEVEL) * ( 0$(SUBLEVEL) <= 255 ) ); \ echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
endef
I like that version.
Two questions: Are there any concerns that KERNEL_VERSION(4, 4, 256) matches KERNEL_VERSION(4, 5. 0), and do you plan to send this patch upstream ?
Thanks, Guenter
On Sat, Feb 06, 2021 at 08:59:42AM -0800, Guenter Roeck wrote:
On 2/6/21 5:22 AM, Willy Tarreau wrote:
On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
Something like this looks more robust to me, it will use SUBLEVEL for values 0 to 255 and 255 for any larger value:
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL <= 255)); \
Bah, I obviously missed a backslash above and forgot spaces around parens. Here's a tested version:
diff --git a/Makefile b/Makefile index 7d86ad6ad36c..9b91b8815b40 100644 --- a/Makefile +++ b/Makefile @@ -1252,7 +1252,7 @@ endef define filechk_version.h echo #define LINUX_VERSION_CODE $(shell \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * ( 0$(SUBLEVEL) > 255 ) + 0$(SUBLEVEL) * ( 0$(SUBLEVEL) <= 255 ) ); \ echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
endef
I like that version.
See the patch that Sasha queued up already, it just fixes it at 255 for now, and we will update with what is in Linus's tree like the above when that gets merged in 5.12-rc1.
Two questions: Are there any concerns that KERNEL_VERSION(4, 4, 256) matches KERNEL_VERSION(4, 5. 0),
As that "release" did nothing, no, I'm not too worried about it, are you?
and do you plan to send this patch upstream ?
See the series sent upstream here: https://lore.kernel.org/r/20210206035033.2036180-1-sashal@kernel.org
thanks,
greg k-h
On Sat, Feb 06, 2021 at 07:13:39PM +0100, Greg Kroah-Hartman wrote:
On Sat, Feb 06, 2021 at 08:59:42AM -0800, Guenter Roeck wrote:
On 2/6/21 5:22 AM, Willy Tarreau wrote:
On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
Something like this looks more robust to me, it will use SUBLEVEL for values 0 to 255 and 255 for any larger value:
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL <= 255)); \
Bah, I obviously missed a backslash above and forgot spaces around parens. Here's a tested version:
diff --git a/Makefile b/Makefile index 7d86ad6ad36c..9b91b8815b40 100644 --- a/Makefile +++ b/Makefile @@ -1252,7 +1252,7 @@ endef define filechk_version.h echo #define LINUX_VERSION_CODE $(shell \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * ( 0$(SUBLEVEL) > 255 ) + 0$(SUBLEVEL) * ( 0$(SUBLEVEL) <= 255 ) ); \ echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
endef
I like that version.
See the patch that Sasha queued up already, it just fixes it at 255 for now, and we will update with what is in Linus's tree like the above when that gets merged in 5.12-rc1.
Two questions: Are there any concerns that KERNEL_VERSION(4, 4, 256) matches KERNEL_VERSION(4, 5. 0),
As that "release" did nothing, no, I'm not too worried about it, are you?
There are lots (35) of "KERNEL_VERSION(4, 5, 0)" in chromeos-4.4. That should not matter with the clamped LINUX_VERSION_CODE, but I'd prefer to clamp KERNEL_VERSION as well just to be sure. On top of that, some of the vendor code we carry along does check SUBVERSION, but that is probably more of an academic concern.
and do you plan to send this patch upstream ?
See the series sent upstream here: https://lore.kernel.org/r/20210206035033.2036180-1-sashal@kernel.org
I backported the relevant patch into chromeos-4.4, so we should be fine.
Thanks! Guenter
On Sat, Feb 06, 2021 at 10:49:26AM -0800, Guenter Roeck wrote:
On Sat, Feb 06, 2021 at 07:13:39PM +0100, Greg Kroah-Hartman wrote:
On Sat, Feb 06, 2021 at 08:59:42AM -0800, Guenter Roeck wrote:
On 2/6/21 5:22 AM, Willy Tarreau wrote:
On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
Something like this looks more robust to me, it will use SUBLEVEL for values 0 to 255 and 255 for any larger value:
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * (0$(SUBLEVEL) > 255) + 0$(SUBLEVEL) * (0$(SUBLEVEL <= 255)); \
Bah, I obviously missed a backslash above and forgot spaces around parens. Here's a tested version:
diff --git a/Makefile b/Makefile index 7d86ad6ad36c..9b91b8815b40 100644 --- a/Makefile +++ b/Makefile @@ -1252,7 +1252,7 @@ endef define filechk_version.h echo #define LINUX_VERSION_CODE $(shell \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * ( 0$(SUBLEVEL) > 255 ) + 0$(SUBLEVEL) * ( 0$(SUBLEVEL) <= 255 ) ); \ echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
endef
I like that version.
See the patch that Sasha queued up already, it just fixes it at 255 for now, and we will update with what is in Linus's tree like the above when that gets merged in 5.12-rc1.
Two questions: Are there any concerns that KERNEL_VERSION(4, 4, 256) matches KERNEL_VERSION(4, 5. 0),
As that "release" did nothing, no, I'm not too worried about it, are you?
There are lots (35) of "KERNEL_VERSION(4, 5, 0)" in chromeos-4.4. That should not matter with the clamped LINUX_VERSION_CODE, but I'd prefer to clamp KERNEL_VERSION as well just to be sure. On top of that, some of the vendor code we carry along does check SUBVERSION, but that is probably more of an academic concern.
Ah, the internal checks, I think the other patch by Sasha will let that get bigger and should work for you as well. Can you try it out?
thanks,
greg k-h
On Sun, Feb 07, 2021 at 09:22:44AM +0100, Greg Kroah-Hartman wrote: [ ... ]
There are lots (35) of "KERNEL_VERSION(4, 5, 0)" in chromeos-4.4. That should not matter with the clamped LINUX_VERSION_CODE, but I'd prefer to clamp KERNEL_VERSION as well just to be sure. On top of that, some of the vendor code we carry along does check SUBVERSION, but that is probably more of an academic concern.
Ah, the internal checks, I think the other patch by Sasha will let that get bigger and should work for you as well. Can you try it out?
Quite frankly I like the "complete" fix much better, but then I dislike deviating from stable releases even more. I'll use Sasha's version.
Thanks, Guenter
On Mon, Feb 08, 2021 at 09:14:53AM -0800, Guenter Roeck wrote:
On Sun, Feb 07, 2021 at 09:22:44AM +0100, Greg Kroah-Hartman wrote: [ ... ]
There are lots (35) of "KERNEL_VERSION(4, 5, 0)" in chromeos-4.4. That should not matter with the clamped LINUX_VERSION_CODE, but I'd prefer to clamp KERNEL_VERSION as well just to be sure. On top of that, some of the vendor code we carry along does check SUBVERSION, but that is probably more of an academic concern.
Ah, the internal checks, I think the other patch by Sasha will let that get bigger and should work for you as well. Can you try it out?
Quite frankly I like the "complete" fix much better, but then I dislike deviating from stable releases even more. I'll use Sasha's version.
We will backport the "complete" fix soon when it hits Linus's tree.
thanks,
greg k-h
From: Willy Tarreau
Sent: 06 February 2021 13:23
On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
Something like this looks more robust to me, it will use SUBLEVEL for values 0 to 255 and 255 for any larger value:
diff --git a/Makefile b/Makefile index 7d86ad6ad36c..9b91b8815b40 100644 --- a/Makefile +++ b/Makefile @@ -1252,7 +1252,7 @@ endef
define filechk_version.h echo #define LINUX_VERSION_CODE $(shell \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * ( 0$(SUBLEVEL) > 255 ) +
0$(SUBLEVEL) * ( 0$(SUBLEVEL) <= 255 ) ); \ echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))' endef
Why not: $(shell echo $$(($(VERSION)<<16 + $(PATCHLEVEL)<<8 + ($(SUBVERSION) < 255 ? $(SUBVERSION) : 255)))) Untested, but I think only the one $ needs any kind of escape. The extra leading zeros do have to go - $((...)) does octal :-(
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
From: David Laight
Sent: 08 February 2021 09:10
From: Willy Tarreau
Sent: 06 February 2021 13:23
On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
Something like this looks more robust to me, it will use SUBLEVEL for values 0 to 255 and 255 for any larger value:
diff --git a/Makefile b/Makefile index 7d86ad6ad36c..9b91b8815b40 100644 --- a/Makefile +++ b/Makefile @@ -1252,7 +1252,7 @@ endef
define filechk_version.h echo #define LINUX_VERSION_CODE $(shell \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * ( 0$(SUBLEVEL) > 255 ) +
0$(SUBLEVEL) * ( 0$(SUBLEVEL) <= 255 ) ); \ echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))' endef
Why not: $(shell echo $$(($(VERSION)<<16 + $(PATCHLEVEL)<<8 + ($(SUBVERSION) < 255 ? $(SUBVERSION) : 255)))) Untested, but I think only the one $ needs any kind of escape. The extra leading zeros do have to go - $((...)) does octal :-(
Or probably even better:
echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + ((c) > 255 ? 255 : (c)))' echo '#define LINUX_VERSION_CODE KERNEL_VERSION($(VERSION), $(PATCHLEVEL)+0, $(SUBLEVEL)+0)'
Which gets rid of the $(shell) as well.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Mon, Feb 08, 2021 at 09:38:05AM +0000, David Laight wrote:
From: David Laight
Sent: 08 February 2021 09:10
From: Willy Tarreau
Sent: 06 February 2021 13:23
On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
Something like this looks more robust to me, it will use SUBLEVEL for values 0 to 255 and 255 for any larger value:
diff --git a/Makefile b/Makefile index 7d86ad6ad36c..9b91b8815b40 100644 --- a/Makefile +++ b/Makefile @@ -1252,7 +1252,7 @@ endef
define filechk_version.h echo #define LINUX_VERSION_CODE $(shell \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \
- expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255 * ( 0$(SUBLEVEL) > 255 ) +
0$(SUBLEVEL) * ( 0$(SUBLEVEL) <= 255 ) ); \ echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))' endef
Why not: $(shell echo $$(($(VERSION)<<16 + $(PATCHLEVEL)<<8 + ($(SUBVERSION) < 255 ? $(SUBVERSION) : 255)))) Untested, but I think only the one $ needs any kind of escape. The extra leading zeros do have to go - $((...)) does octal :-(
Or probably even better:
echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + ((c) > 255 ? 255 : (c)))' echo '#define LINUX_VERSION_CODE KERNEL_VERSION($(VERSION), $(PATCHLEVEL)+0, $(SUBLEVEL)+0)'
Which gets rid of the $(shell) as well.
Please comment on the real patch already submitted by Sasha for this.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
David Laight -
Greg Kroah-Hartman -
Guenter Roeck -
Willy Tarreau