All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.