On Thu, Feb 04, 2021 at 04:28:19PM +0000, David Laight wrote:
From: Jiri Slaby
Sent: 04 February 2021 11:01
On 04. 02. 21, 9:51, Greg Kroah-Hartman wrote:
It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z) assumptions all around the world. So this doesn't look like a good idea.
Ok, so what happens if we "wrap"? What will break with that? At first glance, I can't see anything as we keep the padding the same, and our build scripts seem to pick the number up from the Makefile and treat it like a string.
It's only the crazy out-of-tree kernel stuff that wants to do minor version checks that might go boom. And frankly, I'm not all that concerned if they have problems :)
Agreed. But currently, sublevel won't "wrap", it will "overflow" to patchlevel. And that might be a problem. So we might need to update the header generation using e.g. "sublevel & 0xff" (wrap around) or "sublevel > 255 : 255 : sublevel" (be monotonic and get stuck at 255).
In both LINUX_VERSION_CODE generation and KERNEL_VERSION proper.
A full wrap might catch checks for less than (say) 4.4.2 which might be present to avoid very early versions.
Who does that?
So sticking at 255 or wrapping onto (say) 128 to 255 might be better.
Better how?
I'm actually intrigued about how often you expect people to update systems running these LTS kernels.
Whenever they can, and should.
At a release every week it takes 5 years to run out of sublevels. No one is going to reboot a server anywhere near that often.
Why not?
Usually kernels this old are stuck in legacy embedded systems, like last year's new phone models :)
thanks,
greg k-h