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

[Li Wang <li.wang@linux.dev>]

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

Or, we could achive something simply:

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

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

-- 
Regards,
Li Wang

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