[LTP] [PATCH v5 1/3] lib: adding .supported_archs field in tst_test structure
Richard Palethorpe
rpalethorpe@suse.de
Wed Nov 17 15:25:12 CET 2021
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.
> 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
>
> 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.
I suspect the main issue would be meta-data. As an arbitrarily
complicated kconfig expression may confuse test harnesses.
It might be better for us to tackle that issue and use kconfig though.
--
Thank you,
Richard.
More information about the ltp
mailing list