On Mon, Jan 18, 2021 at 10:21:16AM +0100, Greg KH wrote: > On Sun, Jan 17, 2021 at 08:49:51PM -0500, Sasha Levin wrote: > > 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@xxxxxxxxxx > > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx> > > --- > > 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))' > > As much as I agree, this will break in-tree users of LINUX_VERSION_CODE > that try to suck out the version/patchlevel number of the kernel release > into their own fields. Things like USB host controller strings, v4l > ioctl reports, scsi driver ioctls, and other places do fun bit-movements > to try to unreverse this bit packing. > > So how about we just provide a "real" version/subversion/revision > #define as well, and clean up all in-kernel users, so we can get this to > work, and we can change it in the future more easily. Or, I can just stop doing stable releases at .255 and then abuse the EXTRAVERSION field to put in sub-revision values. Or, we can just not worry about it as anyone using these really old kernels, userspace will work just fine (the number going backwards for these fields isn't going to break anything), it's only any crazy out-of-tree code that will get confused if they are trying to do different build options based on SUBLEVEL :) thanks, greg k-h
