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
