Em Fri, 5 Feb 2021 12:31:05 -0500 Tony Battersby <tonyb@xxxxxxxxxxxxxxx> escreveu: > On 2/4/21 6:00 AM, Jiri Slaby wrote: > > 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. > > My preference would be to be monotonic and get stuck at 255 to avoid > breaking out-of-tree modules. If needed, add another macro that > increases the number of bits that can be used to check for sublevels > > 255, while keeping the old macros for compatibility reasons. Since > sublevels > 255 have never existed before, any such checks must be > newly-added, so they can be required to use the new macros. > > I do not run the 4.4/4.9 kernels usually, but I do sometimes test a wide > range of kernels from 3.18 (gasp!) up to the latest when bisecting, > benchmarking, or debugging problems. And I use a number of out-of-tree > modules that rely on the KERNEL_VERSION to make everything work. Some > out-of-tree modules like an updated igb network driver might be needed > to make it possible to test the old kernel on particular hardware. > > In the worst case, I can patch LINUX_VERSION_CODE and KERNEL_VERSION > locally to make out-of-tree modules work. Or else just not test kernels > with sublevel > 255. Overflowing LINUX_VERSION_CODE breaks media applications. Several media APIs have an ioctl that returns the Kernel version: drivers/media/cec/core/cec-api.c: caps.version = LINUX_VERSION_CODE; drivers/media/mc/mc-device.c: info->media_version = LINUX_VERSION_CODE; drivers/media/v4l2-core/v4l2-ioctl.c: cap->version = LINUX_VERSION_CODE; drivers/media/v4l2-core/v4l2-subdev.c: cap->version = LINUX_VERSION_CODE; Those can be used by applications in order to enable some features that are available only after certain Kernel versions. This is somewhat deprecated, in favor of the usage of some other capability fields, but for instance, the v4l2-compliance userspace tool have two such checks: utils/v4l2-compliance/v4l2-compliance.cpp 640: fail_on_test((vcap.version >> 16) < 3); 641: if (vcap.version >= 0x050900) // Present from 5.9.0 onwards As far as I remember, all such checks are against major.minor. So, something like: sublevel = (sublevel > 0xff) ? 0xff : sublevel; inside KERNEL_VERSION macro should fix such regression at -stable. Thanks, Mauro
