From: Richard Palethorpe <rpalethorpe@suse.de>
To: Joerg Vehlow <lkml@jv-coder.de>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v5 1/3] lib: adding .supported_archs field in tst_test structure
Date: Wed, 17 Nov 2021 14:25:12 +0000 [thread overview]
Message-ID: <87ilwqalvs.fsf@suse.de> (raw)
In-Reply-To: <77e0b8b9-5de6-73ab-0f73-e3d95bad0935@jv-coder.de>
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.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2021-11-17 14:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 7:07 [LTP] [PATCH v5 1/3] lib: adding .supported_archs field in tst_test structure Li Wang
2021-11-17 7:07 ` [LTP] [PATCH v5 2/3] testcase: make use of .supported_archs Li Wang
2021-11-17 7:07 ` [LTP] [PATCH v5 3/3] max_map_count: replace ifdefs by tst_arch Li Wang
2021-11-17 10:33 ` Richard Palethorpe
2021-11-17 13:28 ` Li Wang
2021-11-17 13:58 ` Richard Palethorpe
2021-11-17 9:58 ` [LTP] [PATCH v5 1/3] lib: adding .supported_archs field in tst_test structure Richard Palethorpe
2021-11-17 13:51 ` Li Wang
2021-11-17 14:01 ` Richard Palethorpe
2021-11-18 11:42 ` Cyril Hrubis
2021-11-17 13:59 ` Joerg Vehlow
2021-11-17 14:25 ` Richard Palethorpe [this message]
2021-11-18 5:50 ` Li Wang
2021-11-18 12:07 ` Cyril Hrubis
2021-11-22 2:21 ` Li Wang
2021-11-22 13:27 ` Richard Palethorpe
2021-11-22 14:21 ` Cyril Hrubis
2021-11-23 4:13 ` Li Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ilwqalvs.fsf@suse.de \
--to=rpalethorpe@suse.de \
--cc=lkml@jv-coder.de \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox