Re: [RFC v3][PATCH 0/2] Make ftrace able to trace function return

[Ingo Molnar <mingo@elte.hu>]

* Frédéric Weisbecker <fweisbec@gmail.com> wrote:

> >  2) i cleaned up the arch/x86/Kconfig impact:
> >
> >      f1c4be5: tracing, x86: clean up FUNCTION_RET_TRACER Kconfig
> 
> 
> Ok.
> And concerning the constraint fixed in assembly. That's strange my
> compiler didn't even warn me about it.

yep, that's common with assembly constraints - often the bugs will 
only trigger with certain compilers and with certain config options. 
Generally we've got enough variations of these parameters in -tip 
testing (randconfig plus multiple tools versions) to reliably trigger 
such issues.

> > So lets use "function_full" and "function" tracing perhaps? The 
> > "full" tracer is what traces both entry and exit points, and 
> > establishes full function-call timings/costs. The "function" 
> > tracer is more lightweight and traces function entry events.
> 
> Right. I first chose function_return but it was the largest tracer 
> name and so raised a bug that has been corrected since. And I kept 
> this confusing name.
>
> I'm not sure function_full is really the good one because it's not 
> really a full version of the function tracer. It doesn't do the same 
> thing: when you look into a trace done by the function tracer, the 
> functions appear in order of their call whereas with the function 
> return tracer, they appear in the order of their return which is not 
> the same. The effect is not the same. Why not function_return or 
> something like that?

at the risk of bikeshed-painting this issue too much, the problem with 
function_return is that it has little meaning to actual users and even 
to developers. What does the "return" mean? We know what it means, 
because we know that opposed to function entry we'll also capture 
function returns, and hence be able to do full function call tracing.

so function_full i thought to conduct this aspect of it better. But 
suggestions are welcome.

	Ingo