All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH 1/1] metaparse: Replace macro also in arrays
@ 2022-07-29 15:32 ` Petr Vorel
  0 siblings, 0 replies; 6+ messages in thread
From: Petr Vorel @ 2022-07-29 15:32 UTC (permalink / raw)
  To: ltp; +Cc: Petr Vorel, linux-nfs, Cyril Hrubis, Chen Hanxiao

This helps to replace macros like:

    #define TEST_APP "userns06_capcheck"

    static const char *const resource_files[] = {
	TEST_APP,
	NULL,
    };

$ ./metaparse -Iinclude -Itestcases/kernel/syscalls/utils/ ../testcases/kernel/containers/userns/userns06.c
Before:
   "resource_files": [
     "TEST_APP"
    ],
    ...

After:
   "resource_files": [
     "userns06_capcheck"
    ],
    ...

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
Hi all,

This is a reaction on patch
https://patchwork.ozlabs.org/project/ltp/patch/20220722083529.209-1-chenhx.fnst@fujitsu.com/
First: I was wrong, inlining arrays does any change in the docparse output.
BTW I'd be still for inlining for better readability.

I'm not sure if this is not good idea, maybe some of the constants should be
kept unparsed, e.g.:

Orig:
   "caps": [
     "TST_CAP",
     "(",
     "TST_CAP_DROP",
     "CAP_SYS_RESOURCE",

Becomes:
   "caps": [
     "TST_CAP",
     "(",
     "TST_CAP_DROP",
     "24",

CAP_SYS_RESOURCE is replaced because it's a string, but IMHO it'd be better to keep it.
TST_CAP{_DROP,} aren't replaced because they aren't a plain strings.
Maybe replace only non-numerc values?

Kind regards,
Petr

 metadata/metaparse.c | 43 ++++++++++++++++++++++---------------------
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/metadata/metaparse.c b/metadata/metaparse.c
index 2384c73c8..0cc288b2d 100644
--- a/metadata/metaparse.c
+++ b/metadata/metaparse.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 /*
  * Copyright (c) 2019-2021 Cyril Hrubis <chrubis@suse.cz>
- * Copyright (c) 2020 Petr Vorel <pvorel@suse.cz>
+ * Copyright (c) 2020-2022 Petr Vorel <pvorel@suse.cz>
  */
 
 #define _GNU_SOURCE
@@ -286,9 +286,28 @@ static void close_include(FILE *inc)
 	fclose(inc);
 }
 
+static void try_apply_macro(char **res)
+{
+	ENTRY macro = {
+		.key = *res,
+	};
+
+	ENTRY *ret;
+
+	ret = hsearch(macro, FIND);
+
+	if (!ret)
+		return;
+
+	if (verbose)
+		fprintf(stderr, "APPLYING MACRO %s=%s\n", ret->key, (char*)ret->data);
+
+	*res = ret->data;
+}
+
 static int parse_array(FILE *f, struct data_node *node)
 {
-	const char *token;
+	char *token;
 
 	for (;;) {
 		if (!(token = next_token(f, NULL)))
@@ -315,6 +334,7 @@ static int parse_array(FILE *f, struct data_node *node)
 		if (!strcmp(token, "NULL"))
 			continue;
 
+		try_apply_macro(&token);
 		struct data_node *str = data_node_string(token);
 
 		data_node_array_add(node, str);
@@ -323,25 +343,6 @@ static int parse_array(FILE *f, struct data_node *node)
 	return 0;
 }
 
-static void try_apply_macro(char **res)
-{
-	ENTRY macro = {
-		.key = *res,
-	};
-
-	ENTRY *ret;
-
-	ret = hsearch(macro, FIND);
-
-	if (!ret)
-		return;
-
-	if (verbose)
-		fprintf(stderr, "APPLYING MACRO %s=%s\n", ret->key, (char*)ret->data);
-
-	*res = ret->data;
-}
-
 static int parse_get_array_len(FILE *f)
 {
 	const char *token;
-- 
2.37.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [LTP] [RFC PATCH 1/1] metaparse: Replace macro also in arrays
@ 2022-07-29 15:32 ` Petr Vorel
  0 siblings, 0 replies; 6+ messages in thread
From: Petr Vorel @ 2022-07-29 15:32 UTC (permalink / raw)
  To: ltp; +Cc: linux-nfs

This helps to replace macros like:

    #define TEST_APP "userns06_capcheck"

    static const char *const resource_files[] = {
	TEST_APP,
	NULL,
    };

$ ./metaparse -Iinclude -Itestcases/kernel/syscalls/utils/ ../testcases/kernel/containers/userns/userns06.c
Before:
   "resource_files": [
     "TEST_APP"
    ],
    ...

After:
   "resource_files": [
     "userns06_capcheck"
    ],
    ...

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
Hi all,

This is a reaction on patch
https://patchwork.ozlabs.org/project/ltp/patch/20220722083529.209-1-chenhx.fnst@fujitsu.com/
First: I was wrong, inlining arrays does any change in the docparse output.
BTW I'd be still for inlining for better readability.

I'm not sure if this is not good idea, maybe some of the constants should be
kept unparsed, e.g.:

Orig:
   "caps": [
     "TST_CAP",
     "(",
     "TST_CAP_DROP",
     "CAP_SYS_RESOURCE",

Becomes:
   "caps": [
     "TST_CAP",
     "(",
     "TST_CAP_DROP",
     "24",

CAP_SYS_RESOURCE is replaced because it's a string, but IMHO it'd be better to keep it.
TST_CAP{_DROP,} aren't replaced because they aren't a plain strings.
Maybe replace only non-numerc values?

Kind regards,
Petr

 metadata/metaparse.c | 43 ++++++++++++++++++++++---------------------
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/metadata/metaparse.c b/metadata/metaparse.c
index 2384c73c8..0cc288b2d 100644
--- a/metadata/metaparse.c
+++ b/metadata/metaparse.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 /*
  * Copyright (c) 2019-2021 Cyril Hrubis <chrubis@suse.cz>
- * Copyright (c) 2020 Petr Vorel <pvorel@suse.cz>
+ * Copyright (c) 2020-2022 Petr Vorel <pvorel@suse.cz>
  */
 
 #define _GNU_SOURCE
@@ -286,9 +286,28 @@ static void close_include(FILE *inc)
 	fclose(inc);
 }
 
+static void try_apply_macro(char **res)
+{
+	ENTRY macro = {
+		.key = *res,
+	};
+
+	ENTRY *ret;
+
+	ret = hsearch(macro, FIND);
+
+	if (!ret)
+		return;
+
+	if (verbose)
+		fprintf(stderr, "APPLYING MACRO %s=%s\n", ret->key, (char*)ret->data);
+
+	*res = ret->data;
+}
+
 static int parse_array(FILE *f, struct data_node *node)
 {
-	const char *token;
+	char *token;
 
 	for (;;) {
 		if (!(token = next_token(f, NULL)))
@@ -315,6 +334,7 @@ static int parse_array(FILE *f, struct data_node *node)
 		if (!strcmp(token, "NULL"))
 			continue;
 
+		try_apply_macro(&token);
 		struct data_node *str = data_node_string(token);
 
 		data_node_array_add(node, str);
@@ -323,25 +343,6 @@ static int parse_array(FILE *f, struct data_node *node)
 	return 0;
 }
 
-static void try_apply_macro(char **res)
-{
-	ENTRY macro = {
-		.key = *res,
-	};
-
-	ENTRY *ret;
-
-	ret = hsearch(macro, FIND);
-
-	if (!ret)
-		return;
-
-	if (verbose)
-		fprintf(stderr, "APPLYING MACRO %s=%s\n", ret->key, (char*)ret->data);
-
-	*res = ret->data;
-}
-
 static int parse_get_array_len(FILE *f)
 {
 	const char *token;
-- 
2.37.1


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

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [LTP] [RFC PATCH 1/1] metaparse: Replace macro also in arrays
  2022-07-29 15:32 ` [LTP] " Petr Vorel
@ 2022-08-01 12:51   ` Cyril Hrubis
  -1 siblings, 0 replies; 6+ messages in thread
From: Cyril Hrubis @ 2022-08-01 12:51 UTC (permalink / raw)
  To: Petr Vorel; +Cc: linux-nfs, ltp

Hi!
> This helps to replace macros like:
> 
>     #define TEST_APP "userns06_capcheck"
> 
>     static const char *const resource_files[] = {
> 	TEST_APP,
> 	NULL,
>     };
> 
> $ ./metaparse -Iinclude -Itestcases/kernel/syscalls/utils/ ../testcases/kernel/containers/userns/userns06.c
> Before:
>    "resource_files": [
>      "TEST_APP"
>     ],
>     ...
> 
> After:
>    "resource_files": [
>      "userns06_capcheck"
>     ],
>     ...
> 
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
> Hi all,
> 
> This is a reaction on patch
> https://patchwork.ozlabs.org/project/ltp/patch/20220722083529.209-1-chenhx.fnst@fujitsu.com/
> First: I was wrong, inlining arrays does any change in the docparse output.
> BTW I'd be still for inlining for better readability.
> 
> I'm not sure if this is not good idea, maybe some of the constants should be
> kept unparsed, e.g.:
> 
> Orig:
>    "caps": [
>      "TST_CAP",
>      "(",
>      "TST_CAP_DROP",
>      "CAP_SYS_RESOURCE",
> 
> Becomes:
>    "caps": [
>      "TST_CAP",
>      "(",
>      "TST_CAP_DROP",
>      "24",
> 
> CAP_SYS_RESOURCE is replaced because it's a string, but IMHO it'd be better to keep it.
> TST_CAP{_DROP,} aren't replaced because they aren't a plain strings.
> Maybe replace only non-numerc values?

That really depends on the context, we do have many cases where we have
a macro that expands to numeric that should be expanded, runtime would
be one of the prime examples of that.

I guess that the only solution would be an explicit list of macro
prefixes that should not be expanded, e.g. do not expand if macro starts
with "CAP_".

-- 
Cyril Hrubis
chrubis@suse.cz

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC PATCH 1/1] metaparse: Replace macro also in arrays
@ 2022-08-01 12:51   ` Cyril Hrubis
  0 siblings, 0 replies; 6+ messages in thread
From: Cyril Hrubis @ 2022-08-01 12:51 UTC (permalink / raw)
  To: Petr Vorel; +Cc: ltp, linux-nfs, Chen Hanxiao

Hi!
> This helps to replace macros like:
> 
>     #define TEST_APP "userns06_capcheck"
> 
>     static const char *const resource_files[] = {
> 	TEST_APP,
> 	NULL,
>     };
> 
> $ ./metaparse -Iinclude -Itestcases/kernel/syscalls/utils/ ../testcases/kernel/containers/userns/userns06.c
> Before:
>    "resource_files": [
>      "TEST_APP"
>     ],
>     ...
> 
> After:
>    "resource_files": [
>      "userns06_capcheck"
>     ],
>     ...
> 
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
> Hi all,
> 
> This is a reaction on patch
> https://patchwork.ozlabs.org/project/ltp/patch/20220722083529.209-1-chenhx.fnst@fujitsu.com/
> First: I was wrong, inlining arrays does any change in the docparse output.
> BTW I'd be still for inlining for better readability.
> 
> I'm not sure if this is not good idea, maybe some of the constants should be
> kept unparsed, e.g.:
> 
> Orig:
>    "caps": [
>      "TST_CAP",
>      "(",
>      "TST_CAP_DROP",
>      "CAP_SYS_RESOURCE",
> 
> Becomes:
>    "caps": [
>      "TST_CAP",
>      "(",
>      "TST_CAP_DROP",
>      "24",
> 
> CAP_SYS_RESOURCE is replaced because it's a string, but IMHO it'd be better to keep it.
> TST_CAP{_DROP,} aren't replaced because they aren't a plain strings.
> Maybe replace only non-numerc values?

That really depends on the context, we do have many cases where we have
a macro that expands to numeric that should be expanded, runtime would
be one of the prime examples of that.

I guess that the only solution would be an explicit list of macro
prefixes that should not be expanded, e.g. do not expand if macro starts
with "CAP_".

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC PATCH 1/1] metaparse: Replace macro also in arrays
  2022-08-01 12:51   ` Cyril Hrubis
@ 2022-08-01 14:35     ` Petr Vorel
  -1 siblings, 0 replies; 6+ messages in thread
From: Petr Vorel @ 2022-08-01 14:35 UTC (permalink / raw)
  To: Cyril Hrubis; +Cc: ltp, linux-nfs, Chen Hanxiao

> Hi!
> > This helps to replace macros like:

> >     #define TEST_APP "userns06_capcheck"

> >     static const char *const resource_files[] = {
> > 	TEST_APP,
> > 	NULL,
> >     };

> > $ ./metaparse -Iinclude -Itestcases/kernel/syscalls/utils/ ../testcases/kernel/containers/userns/userns06.c
> > Before:
> >    "resource_files": [
> >      "TEST_APP"
> >     ],
> >     ...

> > After:
> >    "resource_files": [
> >      "userns06_capcheck"
> >     ],
> >     ...

> > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > ---
> > Hi all,

> > This is a reaction on patch
> > https://patchwork.ozlabs.org/project/ltp/patch/20220722083529.209-1-chenhx.fnst@fujitsu.com/
> > First: I was wrong, inlining arrays does any change in the docparse output.
> > BTW I'd be still for inlining for better readability.

> > I'm not sure if this is not good idea, maybe some of the constants should be
> > kept unparsed, e.g.:

> > Orig:
> >    "caps": [
> >      "TST_CAP",
> >      "(",
> >      "TST_CAP_DROP",
> >      "CAP_SYS_RESOURCE",

> > Becomes:
> >    "caps": [
> >      "TST_CAP",
> >      "(",
> >      "TST_CAP_DROP",
> >      "24",

> > CAP_SYS_RESOURCE is replaced because it's a string, but IMHO it'd be better to keep it.
> > TST_CAP{_DROP,} aren't replaced because they aren't a plain strings.
> > Maybe replace only non-numerc values?

> That really depends on the context, we do have many cases where we have
> a macro that expands to numeric that should be expanded, runtime would
> be one of the prime examples of that.
Yep.

> I guess that the only solution would be an explicit list of macro
> prefixes that should not be expanded, e.g. do not expand if macro starts
> with "CAP_".

Good idea, thanks! I was thinking about rewrite parsing to sparse, but you would
not like it as being slow. This is indeed a better solution.

Kind regards,
Petr

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LTP] [RFC PATCH 1/1] metaparse: Replace macro also in arrays
@ 2022-08-01 14:35     ` Petr Vorel
  0 siblings, 0 replies; 6+ messages in thread
From: Petr Vorel @ 2022-08-01 14:35 UTC (permalink / raw)
  To: Cyril Hrubis; +Cc: linux-nfs, ltp

> Hi!
> > This helps to replace macros like:

> >     #define TEST_APP "userns06_capcheck"

> >     static const char *const resource_files[] = {
> > 	TEST_APP,
> > 	NULL,
> >     };

> > $ ./metaparse -Iinclude -Itestcases/kernel/syscalls/utils/ ../testcases/kernel/containers/userns/userns06.c
> > Before:
> >    "resource_files": [
> >      "TEST_APP"
> >     ],
> >     ...

> > After:
> >    "resource_files": [
> >      "userns06_capcheck"
> >     ],
> >     ...

> > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > ---
> > Hi all,

> > This is a reaction on patch
> > https://patchwork.ozlabs.org/project/ltp/patch/20220722083529.209-1-chenhx.fnst@fujitsu.com/
> > First: I was wrong, inlining arrays does any change in the docparse output.
> > BTW I'd be still for inlining for better readability.

> > I'm not sure if this is not good idea, maybe some of the constants should be
> > kept unparsed, e.g.:

> > Orig:
> >    "caps": [
> >      "TST_CAP",
> >      "(",
> >      "TST_CAP_DROP",
> >      "CAP_SYS_RESOURCE",

> > Becomes:
> >    "caps": [
> >      "TST_CAP",
> >      "(",
> >      "TST_CAP_DROP",
> >      "24",

> > CAP_SYS_RESOURCE is replaced because it's a string, but IMHO it'd be better to keep it.
> > TST_CAP{_DROP,} aren't replaced because they aren't a plain strings.
> > Maybe replace only non-numerc values?

> That really depends on the context, we do have many cases where we have
> a macro that expands to numeric that should be expanded, runtime would
> be one of the prime examples of that.
Yep.

> I guess that the only solution would be an explicit list of macro
> prefixes that should not be expanded, e.g. do not expand if macro starts
> with "CAP_".

Good idea, thanks! I was thinking about rewrite parsing to sparse, but you would
not like it as being slow. This is indeed a better solution.

Kind regards,
Petr

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-08-01 14:35 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-29 15:32 [RFC PATCH 1/1] metaparse: Replace macro also in arrays Petr Vorel
2022-07-29 15:32 ` [LTP] " Petr Vorel
2022-08-01 12:51 ` Cyril Hrubis
2022-08-01 12:51   ` Cyril Hrubis
2022-08-01 14:35   ` Petr Vorel
2022-08-01 14:35     ` [LTP] " Petr Vorel

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.