Re: [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting

[Arnaldo Carvalho de Melo]

Em Fri, Aug 19, 2016 at 01:01:43AM +0900, Masami Hiramatsu escreveu:
> On Thu, 18 Aug 2016 11:14:42 -0300
> Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote:
> 
> > Em Thu, Aug 18, 2016 at 05:57:32PM +0900, Masami Hiramatsu escreveu:
> > > Hi Arnaldo and Steven,
> > > 
> > > Here is an RFC series of hexadecimal type casting and
> > > changing default type casting of perf and ftrace.
> > > 
> > > I've introduced x8,x16,x32,x64 according to previous
> > > discussion on LKML.
> > >   https://lkml.org/lkml/2016/8/10/339
> > > 
> > > This series includes not only adding hexadecimal types
> > > (x8,x16,x32,x64), but also checking it is supported by
> > > running kernel and keeping the backward compativility.
> > > 
> > > [1/6] Add hexadecimal type casting, but does not touch
> > >    existing types like 'u8'.
> > > [2/6] Show the supported types on README of ftrace so
> > >    that user application (e.g. perf) can check that.
> > > [3/6] Add a type availability check to perf-probe.
> > > [4/6] Add hexadecimal prefix support to perf-probe if
> > >    it is supported by the kernel. 
> > > [5/6] Change the perf-probe default type casting for
> > >    unsigned type to hexadecimal (for backward compatibility)
> > > [6/6] Change ftrace's 'uNN' to show value in decimal
> > >    and use 'xNN' by default (for backward compatibility)
> > > 
> > > This way, we can also add "octal" type, pointer type,
> > > and "character" type etc. and perf can check whether
> > > the kernel supports it or not. :)
> > 
> > But this requires a kernel update... If we do it all in the tooling
> > side, no kernel changes are required _and_ newer tools will work with
> > older kernels, as this is just a formatting issue, the value is there
> > and from its format one can infer its value, it is not even necessary to
> > look at its "type".
> > 
> > I understand this is necessary for ftrace, because the pretty printer is
> > in the kernel, but I don't see why we would prevent tooling from doing
> > this pretty printing work and make it support any kernel.
> > 
> > I.e. no need at all for checking if the kernel supports anything, just
> > pretty print it.
> 
> That's should be handled by libtraceevent. And if you need just
> a pretty printing, you can do it in python/perl script via perf-script.
> Anyway, to see the event parameters via perf tools, we have to use
> perf-script with/without scripts. As you know, perf-script without
> scripts, the output format depends on libtraceevent. And it seems that
> the libtraceevent output depends on ftrace event "format" file.
 
> And also as you can see in Naohiro's reportã( https://lkml.org/lkml/2016/8/5/191 )
> he was using perf-probe with ftrace trace_pipe interface, which was my
> expected usecase. In that case we have to change ftrace side to
> support various pretty printing.

Sure, if one wants to have pretty printing via trace_pipe, then a kernel
reboot is needed, I'm talking about those who don't want to or can't
reboot their machines :-)

But anyway, your patches allow seeing those events in decimal for people
that can reboot their machine when that wasn't possible without extra
scripting via perl/python, a clear advance!

It remains to be coded a way to achieve the same result without
requiring a kernel reboot, i.e. a tooling only change.
 
> IOW, perf only has very strong pretty printing interface - script
> based output - for trace event arguments. For lighter use cases,
> ftrace provide the print format.
 
> So, I think this is a better meeting point, wouldn't you?

If upgrading the kernel is possible, yes.

- Arnaldo