[LTP] [PATCH] tst_kvercmp: Handle larger kernel version numbers

Petr Vorel pvorel@suse.cz
Wed Oct 25 01:14:29 CEST 2023


Hi Edward,

> Current implementation can only handle revision numbers up to 256.  Bump
> this up to 1024 as some revision numbers are in the 300s.

> Signed-off-by: Edward Liaw <edliaw@google.com>
> ---
>  lib/tst_kvercmp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

> diff --git a/lib/tst_kvercmp.c b/lib/tst_kvercmp.c
> index 552920fac..9e1a511af 100644
> --- a/lib/tst_kvercmp.c
> +++ b/lib/tst_kvercmp.c
> @@ -92,8 +92,8 @@ int tst_kvcmp(const char *cur_kver, int r1, int r2, int r3)
>  		         cur_kver);
>  	}

> -	testver = (r1 << 16) + (r2 << 8) + r3;
> -	currver = (a1 << 16) + (a2 << 8) + a3;
> +	testver = (r1 << 20) + (r2 << 10) + r3;
> +	currver = (a1 << 20) + (a2 << 10) + a3;

I wonder why you need this change. Number > 256 is actually only the third
number, but we haven't checked that so far. Do you plan to use it actually?

We try to detect functional changes to avoid problems to compare about mainline
and *also* with stable/LTS kernels.

NOTE: checking for 3rd number actually does not work for Debian, which reports
`uname -r` as: 5.10.0-8-amd64 (the real version is only as an comment in
/boot/config-*). If something specific in stable would be needed, it would have
to use tst_kvercmp2() (e.g. utimensat01.c for Ubuntu). Maybe you have a similar
problem in AOSP kernel.

Kind regards,
Petr

>  	return currver - testver;
>  }


More information about the ltp mailing list