Re: [RFC] Re: lib: Rename function check_kver() => check_min_kver()

Hi Li, all,

> On Tue, Aug 04, 2026 at 01:33:09PM +0800, Li Wang wrote:
> > Petr Vorel wrote:

> > > Hi all,

> > > > > In that case we want to have both in a single commit, right?
> > > > > => yet another version.

> > > > Yes, I think so

> > > I'm not sure what's reasonable, therefore RFC please.

> > > We can for sure can have test with both flags, .min_kver < .max_kver:

> > > .min_kver = "6.5"
> > > .max_kver = "7.2"

> > > which will be tested on kernels <6.5, 7.2> (including all their stable
> > > versions). Here the code works like (using AND):

> > > $(uname -r) >= .min_kver && $(uname -r) <= .max_kver

> > This above is no porblem.

+1

> > > (BTW although current version prints only the version which is not sufficient.
> > > And I think it's better than print the range without specifying which version is
> > > not sufficient).

> > > But can we have also a variant when .min_kver > .max_kver (using OR)?

> > No, please don't do this :).

> > When I see:

> > 	.min_kver = "7.2",
> > 	.max_kver = "6.10",

> > my first assumption would be that the metadata is wrong,
> > not that it means:

Agree, it'd be confusing.

> > 	kver >= 7.2 || kver <= 6.10

> > So this could easily hide real mistakes. If somebody accidentally
> > swaps the two values, the framework would silently accept it and
> > run the test on a different set of kernels instead of reporting
> > an invalid range.

Agree.

> > I think .min_kver/.max_kver should keep simple AND semantics only,
> > and .min_kver > .max_kver should be rejected, or at least reported
> > as broken test metadata.

I can add this check in new version.


FYI other changes will be
Actually remove any version restriction for creat07.c and execve04.c (ETXTBSY is
required due revert as Cyril found and this revert was backported).

+ what we already discussed:

include/tst_test.h
- * on any stable release (test with ``min_kver = "7.1"`` runs also on kernel
+ * on any stable release (test with ``max_kver = "7.1"`` runs also on kernel

lib/tst_test.c
-       for (i=0, dots=0; max_kver[i]; i++)
+       for (i = 0, dots = 0; max_kver[i]; i++)

> > If we really need to express "run on old kernels and new kernels,
> > but skip a broken middle range", I think it would be better to handle
> > that explicitly in the test code. That would be a bit more verbose,
> > but much easier to read and review.

Agree, but we also loose this info from the metadata.

> Or, we could achive something simply:

>     .supported_kvers = {
>             "<= 6.10",
>             ">= 7.2",
>     },

Using arrays is a good idea, thanks. We would still somehow decide which boolean
should be used (OR or AND), by some flag (e.g. having supported_kvers struct with
array of values and int flag).

> But I don't think there is currently a strong demand for this.

+1. I'd postpone this until it's actually needed (if ever).
Thanks for your feedback!

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp