[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <xhsmh5ygiyem8.mognet@vschneid.remote.csb>
Date: Mon, 17 Oct 2022 10:38:07 +0100
From: Valentin Schneider <vschneid@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Douglas RAILLARD <douglas.raillard@....com>
Subject: Re: [PATCH] tracing: Add __cpumask to denote a trace event field
that is a cpumask_t
On 15/10/22 07:14, Steven Rostedt wrote:
> On Fri, 14 Oct 2022 18:21:41 +0100
> Valentin Schneider <vschneid@...hat.com> wrote:
>>
>> Thanks for spinning this out so quickly! I gave it a test against my IPI
>> tracepoints, it's working OK with one (expected) change:
>
> No problem. It was my "While traveling I pick what I want to work on" project ;-)
>
>>
>> [ipi:ipi_send_cpumask] function __get_cpumask not defined
>> CPU 0 is empty
>> CPU 1 is empty
>> CPU 3 is empty
>> cpus=4
>> echo-173 [002] 11.859745: ipi_send_cpumask: [FAILED TO PARSE] cpumask=ARRAY[02, 00, 00, 00, 00, 00, 00, 00] callsite=0xffffffff81121013
>>
>> so libtraceevent is going to need updating - I'm happy to do that (if you
>> haven't done it already!)
>
> I have not done that. I'm happy to take a patch from you.
>
I'll go do that and try to mess around the pretty-print output as well.
>>
>> Lastly, given all cpumasks have a (usable) size of nr_cpumask_bits, we can
>> factor out the size argument, see below. Regardless:
>
> Seems reasonable. I can fold that into my patch and if you reply back
> with your signed-off-by tag, I'll include you as co-author.
>
Powered by blists - more mailing lists