[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240611133214.3ab0c1a5@gandalf.local.home>
Date: Tue, 11 Jun 2024 13:32:14 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Bart Van Assche <bvanassche@....org>
Cc: Dongliang Cui <dongliang.cui@...soc.com>, axboe@...nel.dk,
mhiramat@...nel.org, mathieu.desnoyers@...icios.com, ebiggers@...nel.org,
ke.wang@...soc.com, hongyu.jin.cn@...il.com, niuzhiguo84@...il.com,
hao_hao.wang@...soc.com, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, akailash@...gle.com,
cuidongliang390@...il.com
Subject: Re: [PATCH v4] block: Add ioprio to block_rq tracepoint
On Tue, 11 Jun 2024 13:17:37 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:
> > Hmm ... if the above array is terminated with a { -1, NULL } sentinel and if
> > __print_symbolic() is changed into trace_print_symbols_seq(p, ...) then the above
> > array can be moved into a C file, isn't it?
> >
>
> Then it breaks user space parsing. The reason for __print_symbolic() is
> that libtraceevent knows how to parse it. If you put the array into a C
> file, the above mappings will not show up in the tracefs format file for
> the event, and you'll just get "[FAILED TO PARSE]" output from the user
> space tracing tooling.
Note, the trace headers are not normal headers. They are included multiple
times (when TRACE_HEADER_MULTI_READ is defined). Only one C file will
include this header with CREATE_TRACE_POINTS defined and these headers will
then build global C functions and variables.
So technically, this "array" is in C file and not in a header, as it will
not be created unless a C file includes it with CREATE_TRACE_POINTS, and
only one C file may do that (otherwise the kernel will fail to build).
-- Steve
Powered by blists - more mailing lists