Re: perf/tracepoints access to interpreted strings

[Arnaldo Carvalho de Melo]

Em Tue, Apr 21, 2015 at 09:07:33AM -0400, Steven Rostedt escreveu:
> On Mon, 20 Apr 2015 15:26:56 -0600 David Ahern <dsahern@xxxxxxxxx> wrote:
> > On 4/20/15 3:25 PM, Arnaldo Carvalho de Melo wrote:
> > > Em Mon, Apr 20, 2015 at 04:46:16PM -0400, Steven Rostedt escreveu:
> > >> On Wed, 15 Apr 2015 15:09:27 -0300 Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote:
> > >> Note, with the new TRACE_DEFINE_ENUM() that was already added to
> > >> Linus's tree, that print_fmt now looks like:

> > >> print fmt: "vec=%u [action=%s]", REC->vec, __print_symbolic(REC->vec,
> > >>   { 0, "HI" }, { 1, "TIMER" }, { 2, "NET_TX" }, { 3, "NET_RX" }, { 4, "BLOCK" },
> > >>   { 5, "BLOCK_IOPOLL" }, { 6, "TASKLET" }, { 7, "SCHED" }, { 8, "HRTIMER" },
> > >>   { 9, "RCU" })

> > > That is better, indeed, covers holes :-)

> > Seems to me that means 2 different implementations are needed ... old 
> > and new.
 
> Why? The above is the way most trace points use __print_symbolic().

I think he is talking about any user space implementation handling those
enum->STR mappings, __print_symbolic() included.

> It's just when a tracepoint uses enums instead of defines or hard coded
> numbers do the useless enum name pops up.
 
> Any parse should be expecting numbers, not enum names.

Humm, I found that the point was that on field 'vec' we receive a
number, and we want to format it to something less cryptic, so we need
to map a number to a string.

The original implementation, that doesn't have that { number, string }
will fail to handle sparse enums, because we can't map number -> "string".

So it has to handle both:

1)    { string, "string" } 
2)    { number, "string" }

And for 1) keep some blacklist of { tracepoint, field-list } that can't
be safely mapped number -> "string", i.e. a blacklist of sparse enums,
no?

David, we could as well just blacklist all kernels where 1) is used and
do no mapping, supporting only 2) kernels. We can do that by parsing
the first element, and if it is not a number, blacklist it.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/