All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it, linux-nfs@vger.kernel.org,
	Chen Hanxiao <chenhx.fnst@fujitsu.com>
Subject: Re: [RFC PATCH 1/1] metaparse: Replace macro also in arrays
Date: Mon, 1 Aug 2022 16:35:25 +0200	[thread overview]
Message-ID: <YufkrU5Z1GCsBhcU@pevik> (raw)
In-Reply-To: <YufMST1r0+ciz2c4@yuki>

> 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

WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: linux-nfs@vger.kernel.org, ltp@lists.linux.it
Subject: Re: [LTP] [RFC PATCH 1/1] metaparse: Replace macro also in arrays
Date: Mon, 1 Aug 2022 16:35:25 +0200	[thread overview]
Message-ID: <YufkrU5Z1GCsBhcU@pevik> (raw)
In-Reply-To: <YufMST1r0+ciz2c4@yuki>

> 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

  reply	other threads:[~2022-08-01 14:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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   ` [LTP] " Cyril Hrubis
2022-08-01 14:35   ` Petr Vorel [this message]
2022-08-01 14:35     ` Petr Vorel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YufkrU5Z1GCsBhcU@pevik \
    --to=pvorel@suse.cz \
    --cc=chenhx.fnst@fujitsu.com \
    --cc=chrubis@suse.cz \
    --cc=linux-nfs@vger.kernel.org \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is 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.