Re: [PATCH v4] block: Add ioprio to block_rq tracepoint

[Steven Rostedt]

On Tue, 11 Jun 2024 10:09:12 -0700
Bart Van Assche <bvanassche@xxxxxxx> wrote:

> On 6/11/24 9:54 AM, Steven Rostedt wrote:
> > On Tue, 11 Jun 2024 09:26:54 -0700
> > Bart Van Assche <bvanassche@xxxxxxx> wrote:
> >   
> >> On 6/11/24 12:35 AM, Dongliang Cui wrote:  
> >>> +#define IOPRIO_CLASS_STRINGS \
> >>> +	{ IOPRIO_CLASS_NONE,	"none" }, \
> >>> +	{ IOPRIO_CLASS_RT,	"rt" }, \
> >>> +	{ IOPRIO_CLASS_BE,	"be" }, \
> >>> +	{ IOPRIO_CLASS_IDLE,	"idle" }, \
> >>> +	{ IOPRIO_CLASS_INVALID,	"invalid"}  
> >>
> >> Shouldn't this array be defined in a C file instead of in a header file?  
> > 
> > The way the TRACE_EVENT() macro works, this will not work in a C file.  
> 
> 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.

-- Steve