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

[Li Wang]

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.


> (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:

	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.

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.

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.

> .max_kver = "6.10"
> .min_kver = "7.2"
> 
> i.e it will be tested on <whatever_minimum_LTP is, 6.10> <7.2, future versions>:
> 
> $(uname -r) <= .max_kver || $(uname -r) >= .min_kver

-- 
Regards,
Li Wang