* [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
@ 2019-06-15 4:20 Li Wang
2019-06-15 4:20 ` [LTP] [PATCH v2 2/3] testcase: taking use of .arch in tst_test Li Wang
` (4 more replies)
0 siblings, 5 replies; 21+ messages in thread
From: Li Wang @ 2019-06-15 4:20 UTC (permalink / raw)
To: ltp
Testcases for specified arch should be limited on that only being supported
platform to run, we now create a function tst_on_arch to achieve this new
feature in LTP library. All you need to run a test on the expected arch is
to set the '.arch' string in the 'struct tst_test' to choose the required
arch list. e.g. '.arch = "x86_64 i386"'.
Signed-off-by: Li Wang <liwang@redhat.com>
---
doc/test-writing-guidelines.txt | 26 ++++++++++
include/tst_arch.h | 16 ++++++
include/tst_test.h | 7 ++-
lib/tst_arch.c | 92 +++++++++++++++++++++++++++++++++
4 files changed, 140 insertions(+), 1 deletion(-)
create mode 100644 include/tst_arch.h
create mode 100644 lib/tst_arch.c
diff --git a/doc/test-writing-guidelines.txt b/doc/test-writing-guidelines.txt
index f1912dc12..b4fba0190 100644
--- a/doc/test-writing-guidelines.txt
+++ b/doc/test-writing-guidelines.txt
@@ -1668,6 +1668,32 @@ sturct tst_test test = {
};
-------------------------------------------------------------------------------
+2.2.30 Testing on specified architecture
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Testcases for specified arch should be limited on that only being supported
+platform to run, we now create a function tst_on_arch to achieve this new
+feature in LTP library. All you need to run a test on the expected arch is
+to set the '.arch' string in the 'struct tst_test' to choose the required
+arch list. e.g. '.arch = "x86_64 i386"'.
+
+[source,c]
+-------------------------------------------------------------------------------
+#include "tst_test.h"
+
+static void setup(void)
+{
+ ...
+}
+
+static struct tst_test test = {
+ ...
+ .setup = setup,
+ .arch = "x86_64 i386",
+ ...
+}
+-------------------------------------------------------------------------------
+
2.3 Writing a testcase in shell
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/include/tst_arch.h b/include/tst_arch.h
new file mode 100644
index 000000000..7bf0493ce
--- /dev/null
+++ b/include/tst_arch.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later
+ * Copyright (c) 2019 Li Wang <liwang@redhat.com>
+ */
+
+#ifndef TST_ARCH_H__
+#define TST_ARCH_H__
+
+/*
+ * Check if test platform is in the given arch list. If yes return 1,
+ * otherwise return 0.
+ *
+ * @arch, NULL or vliad arch list
+ */
+int tst_on_arch(const char *arch);
+
+#endif /* TST_ARCH_H__ */
diff --git a/include/tst_test.h b/include/tst_test.h
index 8bdf38482..cafcb1a89 100644
--- a/include/tst_test.h
+++ b/include/tst_test.h
@@ -28,6 +28,7 @@
#include "tst_atomic.h"
#include "tst_kvercmp.h"
#include "tst_clone.h"
+#include "tst_arch.h"
#include "tst_kernel.h"
#include "tst_minmax.h"
#include "tst_get_bad_addr.h"
@@ -114,6 +115,8 @@ struct tst_test {
const char *min_kver;
+ const char *arch;
+
/* If set the test is compiled out */
const char *tconf_msg;
@@ -253,7 +256,6 @@ const char *tst_strstatus(int status);
unsigned int tst_timeout_remaining(void);
void tst_set_timeout(int timeout);
-
/*
* Returns path to the test temporary directory in a newly allocated buffer.
*/
@@ -265,6 +267,9 @@ static struct tst_test test;
int main(int argc, char *argv[])
{
+ if (!tst_on_arch(test.arch))
+ tst_brk(TCONF, "Test needs running on %s arch!", test.arch);
+
tst_run_tcases(argc, argv, &test);
}
diff --git a/lib/tst_arch.c b/lib/tst_arch.c
new file mode 100644
index 000000000..abc6f0722
--- /dev/null
+++ b/lib/tst_arch.c
@@ -0,0 +1,92 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later
+ * Copyright (c) 2019 Li Wang <liwang@redhat.com>
+ */
+
+#include <string.h>
+#include <stdlib.h>
+
+#define TST_NO_DEFAULT_MAIN
+#include "tst_arch.h"
+#include "tst_test.h"
+
+static const char *const arch_type_list[] = {
+ "i386",
+ "x86",
+ "x86_64",
+ "ia64",
+ "ppc",
+ "ppc64",
+ "s390",
+ "s390x",
+ "arm",
+ "aarch64",
+ "sparc",
+ NULL
+};
+
+static int is_matched_arch(const char *arch, const char *tst_arch)
+{
+ char *dup_arch, *p;
+ const char *delim = " ";
+
+ dup_arch = strdup(arch);
+
+ p = strtok(dup_arch, delim);
+ if (strcmp(p, tst_arch) == 0)
+ return 1;
+
+ while ((p = strtok(NULL, delim))) {
+ if (strcmp(p, tst_arch) == 0)
+ return 1;
+ }
+
+ free(dup_arch);
+ return 0;
+}
+
+static int is_valid_arch(const char *arch)
+{
+ unsigned int i;
+
+ for (i = 0; arch_type_list[i]; i++) {
+ if (is_matched_arch(arch, arch_type_list[i]))
+ return 1;
+ }
+
+ return 0;
+}
+
+int tst_on_arch(const char *arch)
+{
+#if defined(__i386__)
+ char *tst_arch = "i386";
+#elif defined(__x86__)
+ char *tst_arch = "x86";
+#elif defined(__x86_64__)
+ char *tst_arch = "x86_64";
+#elif defined(__ia64__)
+ char *tst_arch = "ia64";
+#elif defined(__powerpc__)
+ char *tst_arch = "ppc";
+#elif defined(__powerpc64__)
+ char *tst_arch = "ppc64";
+#elif defined(__s390__)
+ char *tst_arch = "s390";
+#elif defined(__s390x__)
+ char *tst_arch = "s390x";
+#elif defined(__arm__)
+ char *tst_arch = "arm";
+#elif defined(__arch64__)
+ char *tst_arch = "aarch64";
+#elif defined(__sparc__)
+ char *tst_arch = "sparc";
+#endif
+
+ if (arch != NULL && !is_valid_arch(arch))
+ tst_brk(TBROK, "please set valid arches!");
+
+ if (arch == NULL || is_matched_arch(arch, tst_arch))
+ return 1;
+
+ return 0;
+}
--
2.20.1
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [LTP] [PATCH v2 2/3] testcase: taking use of .arch in tst_test
2019-06-15 4:20 [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure Li Wang
@ 2019-06-15 4:20 ` Li Wang
2019-06-17 21:49 ` Petr Vorel
2019-06-15 4:20 ` [LTP] [PATCH v2 3/3] testcase: get rid of compiling errors Li Wang
` (3 subsequent siblings)
4 siblings, 1 reply; 21+ messages in thread
From: Li Wang @ 2019-06-15 4:20 UTC (permalink / raw)
To: ltp
This is a demo for .arch usage:
1. ptrace07.c, cve-2017-17053.c, meltdown.c
Signed-off-by: Li Wang <liwang@redhat.com>
---
testcases/cve/cve-2017-17053.c | 1 +
testcases/cve/meltdown.c | 9 +--------
testcases/kernel/syscalls/ptrace/ptrace07.c | 8 +++-----
3 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/testcases/cve/cve-2017-17053.c b/testcases/cve/cve-2017-17053.c
index e01db3d4f..62bbc5014 100644
--- a/testcases/cve/cve-2017-17053.c
+++ b/testcases/cve/cve-2017-17053.c
@@ -162,6 +162,7 @@ void run(void)
}
static struct tst_test test = {
+ .arch = "x86_64 i386",
.forks_child = 1,
.setup = setup,
.cleanup = cleanup,
diff --git a/testcases/cve/meltdown.c b/testcases/cve/meltdown.c
index a53ea9b8e..72c9ec907 100644
--- a/testcases/cve/meltdown.c
+++ b/testcases/cve/meltdown.c
@@ -20,8 +20,6 @@
#include "config.h"
#include "tst_test.h"
-#if defined(__x86_64__) || defined(__i386__)
-
#include <stdio.h>
#include <string.h>
#include <signal.h>
@@ -382,15 +380,10 @@ static void cleanup(void)
}
static struct tst_test test = {
+ .arch = "x86_64 i386",
.needs_root = 1,
.setup = setup,
.test_all = run,
.cleanup = cleanup,
.min_kver = "2.6.32"
};
-
-#else /* #if defined(__x86_64__) || defined(__i386__) */
-
-TST_TEST_TCONF("not x86_64 or i386");
-
-#endif /* #else #if defined(__x86_64__) || defined(__i386__) */
diff --git a/testcases/kernel/syscalls/ptrace/ptrace07.c b/testcases/kernel/syscalls/ptrace/ptrace07.c
index 9cbaefc3f..67e47ce16 100644
--- a/testcases/kernel/syscalls/ptrace/ptrace07.c
+++ b/testcases/kernel/syscalls/ptrace/ptrace07.c
@@ -60,13 +60,13 @@
# define NT_X86_XSTATE 0x202
#endif
-#ifdef __x86_64__
static void check_regs_loop(uint32_t initval)
{
const unsigned long num_iters = 1000000000;
uint32_t xmm0[4] = { initval, initval, initval, initval };
int status = 1;
+#ifdef __x86_64__
asm volatile(" movdqu %0, %%xmm0\n"
" mov %0, %%rbx\n"
"1: dec %2\n"
@@ -80,6 +80,7 @@ static void check_regs_loop(uint32_t initval)
"3:\n"
: "+m" (xmm0), "+r" (status)
: "r" (num_iters) : "rax", "rbx", "xmm0");
+#endif
if (status) {
tst_res(TFAIL,
@@ -188,10 +189,7 @@ static void do_test(void)
static struct tst_test test = {
.test_all = do_test,
+ .arch = "x86_64",
.forks_child = 1,
.needs_checkpoints = 1,
};
-
-#else /* !__x86_64__ */
- TST_TEST_TCONF("this test is only supported on x86_64");
-#endif /* __x86_64__ */
--
2.20.1
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [LTP] [PATCH v2 3/3] testcase: get rid of compiling errors
2019-06-15 4:20 [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure Li Wang
2019-06-15 4:20 ` [LTP] [PATCH v2 2/3] testcase: taking use of .arch in tst_test Li Wang
@ 2019-06-15 4:20 ` Li Wang
2019-06-17 21:42 ` Petr Vorel
2019-06-17 21:44 ` Jan Stancek
2019-06-17 21:46 ` [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure Petr Vorel
` (2 subsequent siblings)
4 siblings, 2 replies; 21+ messages in thread
From: Li Wang @ 2019-06-15 4:20 UTC (permalink / raw)
To: ltp
Signed-off-by: Li Wang <liwang@redhat.com>
---
configure.ac | 1 +
testcases/cve/meltdown.c | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/configure.ac b/configure.ac
index 5ecc92781..521f56541 100644
--- a/configure.ac
+++ b/configure.ac
@@ -58,6 +58,7 @@ AC_CHECK_HEADERS([ \
sys/shm.h \
sys/ustat.h \
sys/xattr.h \
+ emmintrin.h \
])
AC_CHECK_FUNCS([ \
diff --git a/testcases/cve/meltdown.c b/testcases/cve/meltdown.c
index 72c9ec907..bc649b893 100644
--- a/testcases/cve/meltdown.c
+++ b/testcases/cve/meltdown.c
@@ -29,6 +29,7 @@
#include <ctype.h>
#include <sys/utsname.h>
+#ifdef HAVE_EMMINTRIN_H
#include <emmintrin.h>
#include "libtsc.h"
@@ -387,3 +388,7 @@ static struct tst_test test = {
.cleanup = cleanup,
.min_kver = "2.6.32"
};
+
+#else /* HAVE_EMMINTRIN_H */
+ TST_TEST_TCONF("<emmintrin.h> is not supported");
+#endif
--
2.20.1
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [LTP] [PATCH v2 3/3] testcase: get rid of compiling errors
2019-06-15 4:20 ` [LTP] [PATCH v2 3/3] testcase: get rid of compiling errors Li Wang
@ 2019-06-17 21:42 ` Petr Vorel
2019-06-17 21:44 ` Jan Stancek
1 sibling, 0 replies; 21+ messages in thread
From: Petr Vorel @ 2019-06-17 21:42 UTC (permalink / raw)
To: ltp
Hi Li,
> Signed-off-by: Li Wang <liwang@redhat.com>
Thanks this patchset.
Acked-by: Petr Vorel <pvorel@suse.cz>
> ---
> configure.ac | 1 +
> testcases/cve/meltdown.c | 5 +++++
> 2 files changed, 6 insertions(+)
> diff --git a/configure.ac b/configure.ac
> index 5ecc92781..521f56541 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -58,6 +58,7 @@ AC_CHECK_HEADERS([ \
> sys/shm.h \
> sys/ustat.h \
> sys/xattr.h \
> + emmintrin.h \
Just AC_CHECK_HEADERS is sorted alphabetically since a50338cac.
But this can be amended during merging.
Kind regards,
Petr
> ])
> AC_CHECK_FUNCS([ \
> diff --git a/testcases/cve/meltdown.c b/testcases/cve/meltdown.c
> index 72c9ec907..bc649b893 100644
> --- a/testcases/cve/meltdown.c
> +++ b/testcases/cve/meltdown.c
> @@ -29,6 +29,7 @@
> #include <ctype.h>
> #include <sys/utsname.h>
> +#ifdef HAVE_EMMINTRIN_H
> #include <emmintrin.h>
> #include "libtsc.h"
> @@ -387,3 +388,7 @@ static struct tst_test test = {
> .cleanup = cleanup,
> .min_kver = "2.6.32"
> };
> +
> +#else /* HAVE_EMMINTRIN_H */
> + TST_TEST_TCONF("<emmintrin.h> is not supported");
> +#endif
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH v2 3/3] testcase: get rid of compiling errors
2019-06-15 4:20 ` [LTP] [PATCH v2 3/3] testcase: get rid of compiling errors Li Wang
2019-06-17 21:42 ` Petr Vorel
@ 2019-06-17 21:44 ` Jan Stancek
2019-06-18 4:03 ` Li Wang
1 sibling, 1 reply; 21+ messages in thread
From: Jan Stancek @ 2019-06-17 21:44 UTC (permalink / raw)
To: ltp
----- Original Message -----
> Signed-off-by: Li Wang <liwang@redhat.com>
> ---
> configure.ac | 1 +
> testcases/cve/meltdown.c | 5 +++++
> 2 files changed, 6 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 5ecc92781..521f56541 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -58,6 +58,7 @@ AC_CHECK_HEADERS([ \
> sys/shm.h \
> sys/ustat.h \
> sys/xattr.h \
> + emmintrin.h \
> ])
>
> AC_CHECK_FUNCS([ \
> diff --git a/testcases/cve/meltdown.c b/testcases/cve/meltdown.c
> index 72c9ec907..bc649b893 100644
> --- a/testcases/cve/meltdown.c
> +++ b/testcases/cve/meltdown.c
> @@ -29,6 +29,7 @@
> #include <ctype.h>
> #include <sys/utsname.h>
>
> +#ifdef HAVE_EMMINTRIN_H
> #include <emmintrin.h>
>
> #include "libtsc.h"
> @@ -387,3 +388,7 @@ static struct tst_test test = {
> .cleanup = cleanup,
> .min_kver = "2.6.32"
> };
> +
> +#else /* HAVE_EMMINTRIN_H */
> + TST_TEST_TCONF("<emmintrin.h> is not supported");
> +#endif
This seems more complicated to me than original - extra autoconf check, extra ifdef.
I can see how tst_on_arch() would be useful. Test is valid on all arches,
but needs different input/constants/code/etc.
What is the motivation for tst_test.arch? Is it to have some annotation in tst_test struct?
> --
> 2.20.1
>
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
2019-06-15 4:20 [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure Li Wang
2019-06-15 4:20 ` [LTP] [PATCH v2 2/3] testcase: taking use of .arch in tst_test Li Wang
2019-06-15 4:20 ` [LTP] [PATCH v2 3/3] testcase: get rid of compiling errors Li Wang
@ 2019-06-17 21:46 ` Petr Vorel
2019-06-18 2:53 ` Li Wang
2019-06-17 21:49 ` Petr Vorel
2021-11-03 12:00 ` Richard Palethorpe
4 siblings, 1 reply; 21+ messages in thread
From: Petr Vorel @ 2019-06-17 21:46 UTC (permalink / raw)
To: ltp
Hi Li,
> Testcases for specified arch should be limited on that only being supported
> platform to run, we now create a function tst_on_arch to achieve this new
> feature in LTP library. All you need to run a test on the expected arch is
> to set the '.arch' string in the 'struct tst_test' to choose the required
> arch list. e.g. '.arch = "x86_64 i386"'.
> Signed-off-by: Li Wang <liwang@redhat.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
LGTM. FYI there is also HOST_CPU variable (since 00ff2c348f),
but that does not help your patch.
> ---
> doc/test-writing-guidelines.txt | 26 ++++++++++
> include/tst_arch.h | 16 ++++++
> include/tst_test.h | 7 ++-
> lib/tst_arch.c | 92 +++++++++++++++++++++++++++++++++
> 4 files changed, 140 insertions(+), 1 deletion(-)
> create mode 100644 include/tst_arch.h
> create mode 100644 lib/tst_arch.c
> diff --git a/doc/test-writing-guidelines.txt b/doc/test-writing-guidelines.txt
> index f1912dc12..b4fba0190 100644
> --- a/doc/test-writing-guidelines.txt
> +++ b/doc/test-writing-guidelines.txt
> @@ -1668,6 +1668,32 @@ sturct tst_test test = {
> };
> -------------------------------------------------------------------------------
> +2.2.30 Testing on specified architecture
^ maybe specific?
Kind regards,
Petr
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
2019-06-15 4:20 [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure Li Wang
` (2 preceding siblings ...)
2019-06-17 21:46 ` [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure Petr Vorel
@ 2019-06-17 21:49 ` Petr Vorel
2019-06-18 3:07 ` Li Wang
2021-11-03 12:00 ` Richard Palethorpe
4 siblings, 1 reply; 21+ messages in thread
From: Petr Vorel @ 2019-06-17 21:49 UTC (permalink / raw)
To: ltp
Hi Li,
> Testcases for specified arch should be limited on that only being supported
> platform to run, we now create a function tst_on_arch to achieve this new
> feature in LTP library. All you need to run a test on the expected arch is
> to set the '.arch' string in the 'struct tst_test' to choose the required
> arch list. e.g. '.arch = "x86_64 i386"'.
Just one note, strings are error prone. I wonder if defining constants and using
array would be too complicated for this use case.
Kind regards,
Petr
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH v2 2/3] testcase: taking use of .arch in tst_test
2019-06-15 4:20 ` [LTP] [PATCH v2 2/3] testcase: taking use of .arch in tst_test Li Wang
@ 2019-06-17 21:49 ` Petr Vorel
0 siblings, 0 replies; 21+ messages in thread
From: Petr Vorel @ 2019-06-17 21:49 UTC (permalink / raw)
To: ltp
Hi Li,
> This is a demo for .arch usage:
> 1. ptrace07.c, cve-2017-17053.c, meltdown.c
> Signed-off-by: Li Wang <liwang@redhat.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Kind regards,
Petr
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
2019-06-17 21:46 ` [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure Petr Vorel
@ 2019-06-18 2:53 ` Li Wang
0 siblings, 0 replies; 21+ messages in thread
From: Li Wang @ 2019-06-18 2:53 UTC (permalink / raw)
To: ltp
On Tue, Jun 18, 2019 at 5:46 AM Petr Vorel <pvorel@suse.cz> wrote:
> Hi Li,
>
> > Testcases for specified arch should be limited on that only being
> supported
> > platform to run, we now create a function tst_on_arch to achieve this new
> > feature in LTP library. All you need to run a test on the expected arch
> is
> > to set the '.arch' string in the 'struct tst_test' to choose the required
> > arch list. e.g. '.arch = "x86_64 i386"'.
>
> > Signed-off-by: Li Wang <liwang@redhat.com>
> Reviewed-by: Petr Vorel <pvorel@suse.cz>
>
> LGTM. FYI there is also HOST_CPU variable (since 00ff2c348f),
> but that does not help your patch.
>
> > ---
> > doc/test-writing-guidelines.txt | 26 ++++++++++
> > include/tst_arch.h | 16 ++++++
> > include/tst_test.h | 7 ++-
> > lib/tst_arch.c | 92 +++++++++++++++++++++++++++++++++
> > 4 files changed, 140 insertions(+), 1 deletion(-)
> > create mode 100644 include/tst_arch.h
> > create mode 100644 lib/tst_arch.c
>
> > diff --git a/doc/test-writing-guidelines.txt
> b/doc/test-writing-guidelines.txt
> > index f1912dc12..b4fba0190 100644
> > --- a/doc/test-writing-guidelines.txt
> > +++ b/doc/test-writing-guidelines.txt
> > @@ -1668,6 +1668,32 @@ sturct tst_test test = {
> > };
> >
> -------------------------------------------------------------------------------
>
> > +2.2.30 Testing on specified architecture
> ^ maybe specific?
>
Agree.
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190618/4025d50c/attachment.html>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
2019-06-17 21:49 ` Petr Vorel
@ 2019-06-18 3:07 ` Li Wang
2019-06-18 5:51 ` Petr Vorel
0 siblings, 1 reply; 21+ messages in thread
From: Li Wang @ 2019-06-18 3:07 UTC (permalink / raw)
To: ltp
On Tue, Jun 18, 2019 at 5:49 AM Petr Vorel <pvorel@suse.cz> wrote:
> Hi Li,
>
> > Testcases for specified arch should be limited on that only being
> supported
> > platform to run, we now create a function tst_on_arch to achieve this new
> > feature in LTP library. All you need to run a test on the expected arch
> is
> > to set the '.arch' string in the 'struct tst_test' to choose the required
> > arch list. e.g. '.arch = "x86_64 i386"'.
> Just one note, strings are error prone. I wonder if defining constants and
> using
> array would be too complicated for this use case.
>
I thought about that array way, but it seems a bit complicted in using.
Yes, strings are easy to involve typo but we can make a check in library.
Thanks for review.
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190618/0d4c72f7/attachment.html>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH v2 3/3] testcase: get rid of compiling errors
2019-06-17 21:44 ` Jan Stancek
@ 2019-06-18 4:03 ` Li Wang
0 siblings, 0 replies; 21+ messages in thread
From: Li Wang @ 2019-06-18 4:03 UTC (permalink / raw)
To: ltp
On Tue, Jun 18, 2019 at 5:44 AM Jan Stancek <jstancek@redhat.com> wrote:
>
> ----- Original Message -----
> > Signed-off-by: Li Wang <liwang@redhat.com>
> > ---
> > configure.ac | 1 +
> > testcases/cve/meltdown.c | 5 +++++
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/configure.ac b/configure.ac
> > index 5ecc92781..521f56541 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -58,6 +58,7 @@ AC_CHECK_HEADERS([ \
> > sys/shm.h \
> > sys/ustat.h \
> > sys/xattr.h \
> > + emmintrin.h \
> > ])
> >
> > AC_CHECK_FUNCS([ \
> > diff --git a/testcases/cve/meltdown.c b/testcases/cve/meltdown.c
> > index 72c9ec907..bc649b893 100644
> > --- a/testcases/cve/meltdown.c
> > +++ b/testcases/cve/meltdown.c
> > @@ -29,6 +29,7 @@
> > #include <ctype.h>
> > #include <sys/utsname.h>
> >
> > +#ifdef HAVE_EMMINTRIN_H
> > #include <emmintrin.h>
> >
> > #include "libtsc.h"
> > @@ -387,3 +388,7 @@ static struct tst_test test = {
> > .cleanup = cleanup,
> > .min_kver = "2.6.32"
> > };
> > +
> > +#else /* HAVE_EMMINTRIN_H */
> > + TST_TEST_TCONF("<emmintrin.h> is not supported");
> > +#endif
>
> This seems more complicated to me than original - extra autoconf check,
> extra ifdef.
>
Indeed.
I choose meltdown.c as a demo randomly, this patch is to solve the
compiling error after removing ifdef __arch__ from code. So, as you can see
the tst_test.arch is not perfect, but it could be used for some general
situations.
> I can see how tst_on_arch() would be useful. Test is valid on all arches,
> but needs different input/constants/code/etc.
>
That's the original reason I exported it in patch v1.
Cyril and I have discussed this part, we think tst_on_arch() is not cleaner
than ifdefs, so it's not suggested to use it directly in a test case.
>
> What is the motivation for tst_test.arch? Is it to have some annotation in
> tst_test struct?
>
The first motivation is to save LTP user from arch ifdefs, moves the
information from code to tst_test metadata, but seems that it can not be
completely replaced because of the specific assembly inline. So I still
hope to find a better way for that, even not go with this tst_test.arch.
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190618/f15ba24d/attachment.html>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
2019-06-18 3:07 ` Li Wang
@ 2019-06-18 5:51 ` Petr Vorel
0 siblings, 0 replies; 21+ messages in thread
From: Petr Vorel @ 2019-06-18 5:51 UTC (permalink / raw)
To: ltp
Hi Li,
> > > Testcases for specified arch should be limited on that only being
> > supported
> > > platform to run, we now create a function tst_on_arch to achieve this new
> > > feature in LTP library. All you need to run a test on the expected arch
> > is
> > > to set the '.arch' string in the 'struct tst_test' to choose the required
> > > arch list. e.g. '.arch = "x86_64 i386"'.
> > Just one note, strings are error prone. I wonder if defining constants and
> > using
> > array would be too complicated for this use case.
> I thought about that array way, but it seems a bit complicted in using.
> Yes, strings are easy to involve typo but we can make a check in library.
OK, agree :).
> Thanks for review.
Kind regards,
Petr
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
2019-06-15 4:20 [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure Li Wang
` (3 preceding siblings ...)
2019-06-17 21:49 ` Petr Vorel
@ 2021-11-03 12:00 ` Richard Palethorpe
2021-11-03 14:03 ` Li Wang
4 siblings, 1 reply; 21+ messages in thread
From: Richard Palethorpe @ 2021-11-03 12:00 UTC (permalink / raw)
To: Li Wang; +Cc: ltp
Hello Li,
Li Wang <liwang@redhat.com> writes:
> Testcases for specified arch should be limited on that only being supported
> platform to run, we now create a function tst_on_arch to achieve this new
> feature in LTP library. All you need to run a test on the expected arch is
> to set the '.arch' string in the 'struct tst_test' to choose the required
> arch list. e.g. '.arch = "x86_64 i386"'.
What is the status of this patch series? Is there a V3?
Maybe another option would be to check the kernel config?
--
Thank you,
Richard.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
2021-11-03 12:00 ` Richard Palethorpe
@ 2021-11-03 14:03 ` Li Wang
2021-11-03 14:10 ` Cyril Hrubis
0 siblings, 1 reply; 21+ messages in thread
From: Li Wang @ 2021-11-03 14:03 UTC (permalink / raw)
To: Richard Palethorpe, Cyril Hrubis; +Cc: LTP List
[-- Attachment #1.1: Type: text/plain, Size: 1089 bytes --]
Hi Richard,
On Wed, Nov 3, 2021 at 8:10 PM Richard Palethorpe <rpalethorpe@suse.de>
wrote:
> Hello Li,
>
> Li Wang <liwang@redhat.com> writes:
>
> > Testcases for specified arch should be limited on that only being
> supported
> > platform to run, we now create a function tst_on_arch to achieve this new
> > feature in LTP library. All you need to run a test on the expected arch
> is
> > to set the '.arch' string in the 'struct tst_test' to choose the required
> > arch list. e.g. '.arch = "x86_64 i386"'.
>
> What is the status of this patch series? Is there a V3?
>
Um, I can't recall why the V3 development for .arch
was suspended.
Maybe we thought there is not much sense to replace
ifdef __arch__ from code at that moment.
Now, if that can benefit the tst_test metadata more in the next runltp-ng.
Should we keep going to work out the patch V3?
@Cyril Hrubis <chrubis@suse.cz> any suggestions?
>
> Maybe another option would be to check the kernel config?
>
That maybe works, but I'm not sure if that can distinguish i386/x86_64 or
ppc64/ppc64le.
--
Regards,
Li Wang
[-- Attachment #1.2: Type: text/html, Size: 2612 bytes --]
[-- Attachment #2: Type: text/plain, Size: 60 bytes --]
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
2021-11-03 14:03 ` Li Wang
@ 2021-11-03 14:10 ` Cyril Hrubis
2021-11-04 10:18 ` Li Wang
0 siblings, 1 reply; 21+ messages in thread
From: Cyril Hrubis @ 2021-11-03 14:10 UTC (permalink / raw)
To: Li Wang; +Cc: LTP List
Hi!
> Um, I can't recall why the V3 development for .arch
> was suspended.
>
> Maybe we thought there is not much sense to replace
> ifdef __arch__ from code at that moment.
>
> Now, if that can benefit the tst_test metadata more in the next runltp-ng.
> Should we keep going to work out the patch V3?
>
> @Cyril Hrubis <chrubis@suse.cz> any suggestions?
Hmm, I guess that I said that it still makes to add the metadata, at
least array of supported architectures in the test_test structure would
be a good addition.
However the hard part would be keeping the actual code and metadata in
sync, we still have to keep the ifdefs in the code.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
2021-11-03 14:10 ` Cyril Hrubis
@ 2021-11-04 10:18 ` Li Wang
2021-11-04 10:26 ` Cyril Hrubis
0 siblings, 1 reply; 21+ messages in thread
From: Li Wang @ 2021-11-04 10:18 UTC (permalink / raw)
To: Cyril Hrubis; +Cc: LTP List
[-- Attachment #1.1: Type: text/plain, Size: 1196 bytes --]
On Wed, Nov 3, 2021 at 10:09 PM Cyril Hrubis <chrubis@suse.cz> wrote:
> Hi!
> > Um, I can't recall why the V3 development for .arch
> > was suspended.
> >
> > Maybe we thought there is not much sense to replace
> > ifdef __arch__ from code at that moment.
> >
> > Now, if that can benefit the tst_test metadata more in the next
> runltp-ng.
> > Should we keep going to work out the patch V3?
> >
> > @Cyril Hrubis <chrubis@suse.cz> any suggestions?
>
> Hmm, I guess that I said that it still makes to add the metadata, at
>
Agreed.
> least array of supported architectures in the test_test structure would
> be a good addition.
>
I guess defining .arch as a string and making a valid check will be enough.
Array for that sounds a bit complicated in use.
>
> However the hard part would be keeping the actual code and metadata in
> sync, we still have to keep the ifdefs in the code.
>
Yes, some inline assemble require ifdefs.
Btw, I look back at the reviews and find Jan said:
"I can see how tst_on_arch() would be useful. Test is valid
on all arches, but needs different input/constants/code/etc."
That may be a slight reason for keeping tst_on_arch.
--
Regards,
Li Wang
[-- Attachment #1.2: Type: text/html, Size: 3053 bytes --]
[-- Attachment #2: Type: text/plain, Size: 60 bytes --]
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
2021-11-04 10:18 ` Li Wang
@ 2021-11-04 10:26 ` Cyril Hrubis
2021-11-05 9:47 ` Richard Palethorpe
0 siblings, 1 reply; 21+ messages in thread
From: Cyril Hrubis @ 2021-11-04 10:26 UTC (permalink / raw)
To: Li Wang; +Cc: LTP List
Hi!
> > least array of supported architectures in the test_test structure would
> > be a good addition.
> >
>
> I guess defining .arch as a string and making a valid check will be enough.
> Array for that sounds a bit complicated in use.
Quite the opposite, it should be an array of strings, so that it's easy
to work with such as:
.supported_archs = (const char *const []){"x86_64", "ppc64le", NULL},
We can put it into a single string delimited by a space, but that would
be more complicated to work with.
> > However the hard part would be keeping the actual code and metadata in
> > sync, we still have to keep the ifdefs in the code.
> >
>
> Yes, some inline assemble require ifdefs.
>
> Btw, I look back at the reviews and find Jan said:
> "I can see how tst_on_arch() would be useful. Test is valid
> on all arches, but needs different input/constants/code/etc."
>
> That may be a slight reason for keeping tst_on_arch.
I guess that we should reviewe the code we have, I guess that there are
a few tests where we can get rid of a few ifdefs by doing the checks
dynamically.
Also I guess that it would be slightly easier to work with as an enum,
so that we can do:
switch (tst_arch) {
case TST_X86_64:
...
break;
case TST_PPC64_LE:
...
break;
default:
...
break;
}
instead of:
if (!strcmp(tst_arch, "x86_64"))
...
else if (!strmcp(tst_arch, ...)))
...
else
...
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
2021-11-04 10:26 ` Cyril Hrubis
@ 2021-11-05 9:47 ` Richard Palethorpe
2021-11-05 13:23 ` Li Wang
0 siblings, 1 reply; 21+ messages in thread
From: Richard Palethorpe @ 2021-11-05 9:47 UTC (permalink / raw)
To: Cyril Hrubis; +Cc: LTP List
Hello,
Cyril Hrubis <chrubis@suse.cz> writes:
> Hi!
>> > least array of supported architectures in the test_test structure would
>> > be a good addition.
>> >
>>
>> I guess defining .arch as a string and making a valid check will be enough.
>> Array for that sounds a bit complicated in use.
>
> Quite the opposite, it should be an array of strings, so that it's easy
> to work with such as:
>
> .supported_archs = (const char *const []){"x86_64", "ppc64le", NULL},
>
> We can put it into a single string delimited by a space, but that would
> be more complicated to work with.
>
>> > However the hard part would be keeping the actual code and metadata in
>> > sync, we still have to keep the ifdefs in the code.
>> >
>>
>> Yes, some inline assemble require ifdefs.
>>
>> Btw, I look back at the reviews and find Jan said:
>> "I can see how tst_on_arch() would be useful. Test is valid
>> on all arches, but needs different input/constants/code/etc."
>>
>> That may be a slight reason for keeping tst_on_arch.
>
> I guess that we should reviewe the code we have, I guess that there are
> a few tests where we can get rid of a few ifdefs by doing the checks
> dynamically.
>
> Also I guess that it would be slightly easier to work with as an enum,
> so that we can do:
>
> switch (tst_arch) {
> case TST_X86_64:
> ...
> break;
> case TST_PPC64_LE:
I prefer enum as well. As an aside, we don't want to include LE in
ppc64. If someone finds that the byte order is significant for a test
then we can add ppc64le or ppc64be. Also at some point we may need to
add a "machine" field for e.g. POWER8, i386 etc.
Which btw, I have some buildroot and QEMU scripts which can be used to
test ppc64 BE and any other machine you have the hardware or QEMU
emulator for.
https://gitlab.com/Palethorpe/cross
> ...
> break;
> default:
> ...
> break;
> }
>
> instead of:
> if (!strcmp(tst_arch, "x86_64"))
> ...
> else if (!strmcp(tst_arch, ...)))
> ...
> else
> ...
--
Thank you,
Richard.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
2021-11-05 9:47 ` Richard Palethorpe
@ 2021-11-05 13:23 ` Li Wang
2021-11-05 13:55 ` Richard Palethorpe
2021-11-05 14:22 ` Cyril Hrubis
0 siblings, 2 replies; 21+ messages in thread
From: Li Wang @ 2021-11-05 13:23 UTC (permalink / raw)
To: Richard Palethorpe; +Cc: LTP List
[-- Attachment #1.1: Type: text/plain, Size: 2522 bytes --]
> > Quite the opposite, it should be an array of strings, so that it's easy
> > to work with such as:
> >
> > .supported_archs = (const char *const []){"x86_64", "ppc64le",
> NULL},
> >
> > We can put it into a single string delimited by a space, but that would
> > be more complicated to work with.
> >
> >> > However the hard part would be keeping the actual code and metadata in
> >> > sync, we still have to keep the ifdefs in the code.
> >> >
> >>
> >> Yes, some inline assemble require ifdefs.
> >>
> >> Btw, I look back at the reviews and find Jan said:
> >> "I can see how tst_on_arch() would be useful. Test is valid
> >> on all arches, but needs different input/constants/code/etc."
> >>
> >> That may be a slight reason for keeping tst_on_arch.
> >
> > I guess that we should reviewe the code we have, I guess that there are
> > a few tests where we can get rid of a few ifdefs by doing the checks
> > dynamically.
> >
> > Also I guess that it would be slightly easier to work with as an enum,
> > so that we can do:
> >
> > switch (tst_arch) {
> > case TST_X86_64:
> > ...
> > break;
> > case TST_PPC64_LE:
>
> I prefer enum as well. As an aside, we don't want to include LE in
>
Sure, but I'm now thinking to extend the tst_arch as a structure
so that could also be used in a string:
enum tst_arch_type {
TST_I386,
TST_X86_64,
...
TST_SPARC,
};
/*
* This tst_arch is to save the system architecture for
* using in the whole test case.
*/
extern struct arch {
const char name[16];
enum tst_arch_type type;
} tst_arch;
then we just can do simply in case:
switch (tst_arch.type) {
case TST_X86_64:
...
break;
> ppc64. If someone finds that the byte order is significant for a test
>
Yes, or we can read info via uname() into 'utsname.machine' for
ppc64le if really needed.
> then we can add ppc64le or ppc64be. Also at some point we may need to
> add a "machine" field for e.g. POWER8, i386 etc.
>
Adding a new field '.machine' maybe not be necessary if just
for POWER8/9/10, or can we find a way to combine them together
with .supported_arch? Umm, I'm still hesitating.
>
> Which btw, I have some buildroot and QEMU scripts which can be used to
> test ppc64 BE and any other machine you have the hardware or QEMU
> emulator for.
>
> https://gitlab.com/Palethorpe/cross
Thanks for sharing.
--
Regards,
Li Wang
[-- Attachment #1.2: Type: text/html, Size: 5858 bytes --]
[-- Attachment #2: Type: text/plain, Size: 60 bytes --]
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
2021-11-05 13:23 ` Li Wang
@ 2021-11-05 13:55 ` Richard Palethorpe
2021-11-05 14:22 ` Cyril Hrubis
1 sibling, 0 replies; 21+ messages in thread
From: Richard Palethorpe @ 2021-11-05 13:55 UTC (permalink / raw)
To: Li Wang; +Cc: LTP List
Hell Li,
Li Wang <liwang@redhat.com> writes:
>
>
> > Quite the opposite, it should be an array of strings, so that it's easy
> > to work with such as:
> >
> > .supported_archs = (const char *const []){"x86_64", "ppc64le", NULL},
> >
> > We can put it into a single string delimited by a space, but that would
> > be more complicated to work with.
> >
> >> > However the hard part would be keeping the actual code and metadata in
> >> > sync, we still have to keep the ifdefs in the code.
> >> >
> >>
> >> Yes, some inline assemble require ifdefs.
> >>
> >> Btw, I look back at the reviews and find Jan said:
> >> "I can see how tst_on_arch() would be useful. Test is valid
> >> on all arches, but needs different input/constants/code/etc."
> >>
> >> That may be a slight reason for keeping tst_on_arch.
> >
> > I guess that we should reviewe the code we have, I guess that there are
> > a few tests where we can get rid of a few ifdefs by doing the checks
> > dynamically.
> >
> > Also I guess that it would be slightly easier to work with as an enum,
> > so that we can do:
> >
> > switch (tst_arch) {
> > case TST_X86_64:
> > ...
> > break;
> > case TST_PPC64_LE:
>
> I prefer enum as well. As an aside, we don't want to include LE in
>
> Sure, but I'm now thinking to extend the tst_arch as a structure
> so that could also be used in a string:
+1
>
> enum tst_arch_type {
> TST_I386,
> TST_X86_64,
> ...
> TST_SPARC,
> };
>
> /*
> * This tst_arch is to save the system architecture for
> * using in the whole test case.
> */
> extern struct arch {
> const char name[16];
> enum tst_arch_type type;
> } tst_arch;
>
> then we just can do simply in case:
>
> switch (tst_arch.type) {
> case TST_X86_64:
> ...
> break;
>
>
> ppc64. If someone finds that the byte order is significant for a test
>
> Yes, or we can read info via uname() into 'utsname.machine' for
> ppc64le if really needed.
>
> then we can add ppc64le or ppc64be. Also at some point we may need to
> add a "machine" field for e.g. POWER8, i386 etc.
>
> Adding a new field '.machine' maybe not be necessary if just
> for POWER8/9/10, or can we find a way to combine them together
> with .supported_arch? Umm, I'm still hesitating.
If it's required then I guess you could add it to the tst_arch_type as
an optional field. Perhaps as cpu_model. Or it could be added to a
separate section for required hardware.
>
>
> Which btw, I have some buildroot and QEMU scripts which can be used to
> test ppc64 BE and any other machine you have the hardware or QEMU
> emulator for.
>
> https://gitlab.com/Palethorpe/cross
>
> Thanks for sharing.
--
Thank you,
Richard.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure
2021-11-05 13:23 ` Li Wang
2021-11-05 13:55 ` Richard Palethorpe
@ 2021-11-05 14:22 ` Cyril Hrubis
1 sibling, 0 replies; 21+ messages in thread
From: Cyril Hrubis @ 2021-11-05 14:22 UTC (permalink / raw)
To: Li Wang; +Cc: LTP List
Hi!
> > > Also I guess that it would be slightly easier to work with as an enum,
> > > so that we can do:
> > >
> > > switch (tst_arch) {
> > > case TST_X86_64:
> > > ...
> > > break;
> > > case TST_PPC64_LE:
> >
> > I prefer enum as well. As an aside, we don't want to include LE in
> >
>
> Sure, but I'm now thinking to extend the tst_arch as a structure
> so that could also be used in a string:
>
> enum tst_arch_type {
> TST_I386,
> TST_X86_64,
> ...
> TST_SPARC,
> };
>
> /*
> * This tst_arch is to save the system architecture for
> * using in the whole test case.
> */
> extern struct arch {
> const char name[16];
> enum tst_arch_type type;
> } tst_arch;
Or we can add a function to translate the enums into strings as:
const char *tst_arch_name(enum tst_arch arch);
> then we just can do simply in case:
>
> switch (tst_arch.type) {
> case TST_X86_64:
> ...
> break;
>
>
>
> > ppc64. If someone finds that the byte order is significant for a test
> >
>
> Yes, or we can read info via uname() into 'utsname.machine' for
> ppc64le if really needed.
>
>
> > then we can add ppc64le or ppc64be. Also at some point we may need to
> > add a "machine" field for e.g. POWER8, i386 etc.
> >
>
> Adding a new field '.machine' maybe not be necessary if just
> for POWER8/9/10, or can we find a way to combine them together
> with .supported_arch? Umm, I'm still hesitating.
This is going to get complicated quite fast. I do not think that we need
such granularity now, but if we ever do I think it can be done as a
subtype. E.g.:
enum tst_arch {
TST_X86,
TST_X86_64,
TST_PPC64,
};
enum tst_x86_subarch {
TST_386,
TST_486,
TST_686,
};
enum tst_ppc_subarch {
{
TST_POWER8,
TST_POWER9,
TST_POWER10,
};
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2021-11-05 14:21 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-15 4:20 [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure Li Wang
2019-06-15 4:20 ` [LTP] [PATCH v2 2/3] testcase: taking use of .arch in tst_test Li Wang
2019-06-17 21:49 ` Petr Vorel
2019-06-15 4:20 ` [LTP] [PATCH v2 3/3] testcase: get rid of compiling errors Li Wang
2019-06-17 21:42 ` Petr Vorel
2019-06-17 21:44 ` Jan Stancek
2019-06-18 4:03 ` Li Wang
2019-06-17 21:46 ` [LTP] [PATCH v2 1/3] lib: adding .arch field in tst_test structure Petr Vorel
2019-06-18 2:53 ` Li Wang
2019-06-17 21:49 ` Petr Vorel
2019-06-18 3:07 ` Li Wang
2019-06-18 5:51 ` Petr Vorel
2021-11-03 12:00 ` Richard Palethorpe
2021-11-03 14:03 ` Li Wang
2021-11-03 14:10 ` Cyril Hrubis
2021-11-04 10:18 ` Li Wang
2021-11-04 10:26 ` Cyril Hrubis
2021-11-05 9:47 ` Richard Palethorpe
2021-11-05 13:23 ` Li Wang
2021-11-05 13:55 ` Richard Palethorpe
2021-11-05 14:22 ` Cyril Hrubis
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.