From: Douglas Raillard <douglas.raillard@arm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org,
Masami Hiramatsu <mhiramat@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Valentin Schneider <vschneid@redhat.com>
Subject: Re: [for-next][PATCH 02/11] tracing: Add __cpumask to denote a trace event field that is a cpumask_t
Date: Tue, 13 Dec 2022 19:50:18 +0000 [thread overview]
Message-ID: <3a11ed33-0a3d-2668-ab2b-c44eea7eddbe@arm.com> (raw)
In-Reply-To: <764f8b9a-2111-c260-7f2c-89eb9f0ac7a3@arm.com>
On 13-12-2022 14:20, Douglas Raillard wrote:
>
> The only case I can think of where parsing would not follow regular C abstract declaration syntax is a type like that:
>
> __data_loc int [3][]
After some experimentation, I came to the conclusion that "__data_loc <type> [] <id>" can indeed support any C type if they
need to be added in the future. I would heavily suggest that any future extension works as the following, to avoid messing up
the grammar in a subtle way that would prevent some types to be expressible, or make it a nightmare to implement.
The recipe to parse that with stock C parser is:
* consume "__data_loc"
* parse "<type> []" as a func prototype parameter declaration
(declaration using an abstract declarator, i.e. not introducing any identifier)
* parse "<id>" as an identifier.
> The outer-most array is by definition the dynamic one, so "[]". In normal C, [3] and [] would be swapped as
> the outer-most array comes first. That's not too bad though as it is not ambiguous and easy to fixup directly
> in the parse tree.
Simply swapping is wrong in the general case. The correct modification of the "<type> []" parse tree is doing a
"barrel shift" on nested array sizes. If the type is "int [1][2][]", it needs to be turned into "int [][1][2]".
The now-top-level sizeless array is the dynamic array. Note that pointers level are transparent,
so "int (*[1])[2][]" needs to be turned into "int (*[])[1][2]"
-- Douglas
next prev parent reply other threads:[~2022-12-13 19:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-24 14:50 [for-next][PATCH 00/11] tracing: Updates for 6.2 Steven Rostedt
2022-11-24 14:50 ` [for-next][PATCH 01/11] ftrace: Clean comments related to FTRACE_OPS_FL_PER_CPU Steven Rostedt
2022-11-24 14:50 ` [for-next][PATCH 02/11] tracing: Add __cpumask to denote a trace event field that is a cpumask_t Steven Rostedt
2022-12-12 14:53 ` Douglas Raillard
2022-12-12 16:12 ` Steven Rostedt
2022-12-12 17:04 ` Steven Rostedt
2022-12-12 22:19 ` Douglas Raillard
2022-12-12 23:53 ` Steven Rostedt
2022-12-13 14:20 ` Douglas Raillard
2022-12-13 15:11 ` Steven Rostedt
2022-12-13 17:40 ` Douglas Raillard
2022-12-13 19:44 ` Steven Rostedt
2022-12-13 21:14 ` Douglas Raillard
2022-12-13 19:50 ` Douglas Raillard [this message]
2022-11-24 14:50 ` [for-next][PATCH 03/11] tracing: Add trace_trigger kernel command line option Steven Rostedt
2022-11-24 14:50 ` [for-next][PATCH 04/11] ring_buffer: Remove unused "event" parameter Steven Rostedt
2022-11-24 14:50 ` [for-next][PATCH 05/11] tracing/osnoise: Add osnoise/options file Steven Rostedt
2022-11-24 17:31 ` Daniel Bristot de Oliveira
2022-11-24 19:28 ` Steven Rostedt
2022-11-24 14:50 ` [for-next][PATCH 06/11] tracing/osnoise: Add OSNOISE_WORKLOAD option Steven Rostedt
2022-11-24 14:50 ` [for-next][PATCH 07/11] Documentation/osnoise: Add osnoise/options documentation Steven Rostedt
2022-11-24 14:50 ` [for-next][PATCH 08/11] tracing/perf: Use strndup_user instead of kzalloc/strncpy_from_user Steven Rostedt
2022-11-24 14:50 ` [for-next][PATCH 09/11] tracing: Make tracepoint_print_iter static Steven Rostedt
2022-11-24 14:50 ` [for-next][PATCH 11/11] ftrace: Avoid needless updates of the ftrace function call Steven Rostedt
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=3a11ed33-0a3d-2668-ab2b-c44eea7eddbe@arm.com \
--to=douglas.raillard@arm.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).