[LTP] [PATCH v5 1/3] lib: adding .supported_archs field in tst_test structure

[Li Wang]

Hi Joerg, Richard,

On Wed, Nov 17, 2021 at 10:37 PM Richard Palethorpe <rpalethorpe@suse.de>
wrote:

> Hello Joerg,
>
> Joerg Vehlow <lkml@jv-coder.de> writes:
>
> > Hi,
> >
> > On 11/17/2021 8:07 AM, Li Wang wrote:
> >> Testcases for specific arch should be limited on that only being
> supported
> >> platform to run, we now involve a .supported_archs to achieve this
> feature
> >> in LTP library. All you need to run a test on the expected arch is to
> set
> >> the '.supported_archs' array in the 'struct tst_test' to choose the
> required
> >> arch list. e.g.
> >>
> >>      .supported_archs = (const char *const []){"x86_64", "ppc64", NULL}
> >>
> >> This helps move the TCONF info from code to tst_test metadata as well.
> >
> > while I do like this, I wonder if it wouldn't be better to do this
> > using kernel config. IIRC there are config switches
> > for all architectures. Further more this would allow adding more
> > complex conditions in the future.
> >
> > E.g: I am pretty sure, that there are some syscalls, that have existed
> > "forever" in x86_64, but where only added
> > in a specific version for aarch64. By making the arch a separate
> > option, there is no way, to model this.
>

Umm, we shouldn't set .supported_archs to make it a separate option
unless we have an explicit requirement on that. In other words, without
that .supported_archs setting, it will support all arches by default and we
can do anything by the exported tst_arch structure and enum tst_arch_type.



> > If it was done in the kernel config check, it could be possible to add
> > version and arch checks like
> > (CONFIG_AARCH64 && CONFIG_VERSION > 5.3) || CONFIG_X86_64
>

We definitely can achieve this in the current version as well.

    switch (tst_arch.type)
    case TST_AARCH64:
            if ((tst_kvercmp(5, 3, 0)) < 0)
                    break;
    case TST_X86_64:
            ltp_syscall(__NR_special_syscall, ...)
    break;
        ...



> >
> > While this probably does not produce a very good error message, it is
> > more versatile.
> >
> > Sorry for this late questioning the whole approach.
>
> It should never be too late IMO. We should also consider whether there
> are existing tst_test flags which have been made redundant by kconfig.
>

After checking the config file again, yes, I agree that we can achieve the
same thing just with existing kconfig functions to parse it.

E.g. If required x86_64:

    .needs_kconfigs = (const char *[]) {
        "CONFIG_X86_64=y",
        NULL
    },

and s390x will be like:

    .needs_kconfigs = (const char *[]) {
        "CONFIG_64BIT=y",
        "CONFIG_S390=y"
        NULL
    },

...


>
> I suspect the main issue would be meta-data. As an arbitrarily
> complicated kconfig expression may confuse test harnesses.
>

Right, so I would like to keep the .supported_archs and tst_arch structure
no change, even though goes with parsing config file in the library.



>
> It might be better for us to tackle that issue and use kconfig though.
>
> --
> Thank you,
> Richard.
>
>

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20211118/01145b72/attachment.htm>