Re: [RFC] Re: lib: Rename function check_kver() => check_min_kver()
Li Wang <[email protected]> Tue, 4 Aug 2026 14:15:07 +0800
| Newsgroups | gmane.linux.ltp |
|---|---|
| Message-ID | <[email protected]> |
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