Linux Test Project
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
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: Thu, 18 Nov 2021 13:07:29 +0100	[thread overview]
Message-ID: <YZZCAXWRcrsYJo9+@yuki> (raw)
In-Reply-To: <77e0b8b9-5de6-73ab-0f73-e3d95bad0935@jv-coder.de>

Hi!
> > 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.

Not at all, this is a good point.

The main problem is that the kernel architecture does not need to match
the binary architecture which is what this patchset tries to cover. That
means that 32bit binary on 64bit kernel would not match what we are
supposed to match. Even more the config variables are confusing, on
x86_64 with compat layer enabled we get:

CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y

That makes any reasoning quite messy.

What would make much more sense would be injecting LTP specific
variables to the parsed variables before evaluation. So for instance we
would insert BINARY_ARCH variable which would cover this exact case and
the check would look like:

"(BINARY_ARCH == "aarch64" && CONFIG_VERSION > 5.3) || CONFIG_X86_64"

However I would still like to have a simple list of supported
architectures in the test structure as well, since that is much easier
to read and reason about and it covers 99% of the cases. Nothing stops
us for adding the more complex checks in the case that we see the need
later on.

-- 
Cyril Hrubis
chrubis@suse.cz

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

  parent reply	other threads:[~2021-11-18 12:06 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
2021-11-18  5:50     ` Li Wang
2021-11-18 12:07   ` Cyril Hrubis [this message]
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=YZZCAXWRcrsYJo9+@yuki \
    --to=chrubis@suse.cz \
    --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