linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Tony Battersby <tonyb@cybernetics.com>
Cc: Jiri Slaby <jirislaby@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	Jari Ruusu <jariruusu@protonmail.com>,
	David Laight <David.Laight@ACULAB.COM>,
	Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>,
	linux-media@vger.kernel.org
Subject: Re: Kernel version numbers after 4.9.255 and 4.4.255
Date: Fri, 5 Feb 2021 19:11:05 +0100	[thread overview]
Message-ID: <20210205191105.128c6e48@coco.lan> (raw)
In-Reply-To: <0b12bac9-1b4e-ec4a-8a45-5eb3f1dbbeca@cybernetics.com>

Em Fri, 5 Feb 2021 12:31:05 -0500
Tony Battersby <tonyb@cybernetics.com> 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

  reply	other threads:[~2021-02-05 18:52 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-04  5:59 Jari Ruusu
2021-02-04  6:20 ` Greg Kroah-Hartman
2021-02-04  7:26   ` Jiri Slaby
2021-02-04  8:51     ` Greg Kroah-Hartman
2021-02-04 11:00       ` Jiri Slaby
2021-02-04 16:28         ` David Laight
2021-02-04 16:48           ` Greg Kroah-Hartman
2021-02-04 20:19           ` Christoph Biedl
2021-02-05  6:52             ` Greg KH
2021-02-05 17:31         ` Tony Battersby
2021-02-05 18:11           ` Mauro Carvalho Chehab [this message]
2021-02-06  7:20             ` Greg Kroah-Hartman
2021-02-06  9:24               ` Mauro Carvalho Chehab
2021-02-06  9:29                 ` Greg Kroah-Hartman
2021-02-06  9:48                   ` Mauro Carvalho Chehab
2021-02-06 10:18                     ` Hans Verkuil
2021-02-06 11:18                       ` Mauro Carvalho Chehab
2021-02-06  7:22           ` Greg Kroah-Hartman
2021-02-05  9:06       ` Pavel Machek
2021-02-05  9:33         ` Greg Kroah-Hartman
2021-02-05 18:44           ` Pavel Machek
2021-02-06  7:23             ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210205191105.128c6e48@coco.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=David.Laight@ACULAB.COM \
    --cc=gregkh@linuxfoundation.org \
    --cc=jariruusu@protonmail.com \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel.bfrz@manchmal.in-ulm.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=tonyb@cybernetics.com \
    --subject='Re: Kernel version numbers after 4.9.255 and 4.4.255' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).