Re: [RFC PATCH 09/10] tracing: Use the hashlist for graph function

[Frederic Weisbecker <fweisbec@gmail.com>]

On Mon, Jan 25, 2010 at 04:50:48PM +0800, Lai Jiangshan wrote:
> Frederic Weisbecker wrote:
> > When we set a filter to start tracing from a given function in
> > the function graph tracer, the filter is stored in a linear array.
> > 
> > It doesn't scale very well, we even limited the number of such
> > functions to 32.
> > 
> > Now that we have a hashlist of functions, lets put a field inside
> > each function node so that we can check if a function is one of
> > these filters using the hashlist, not a linear array.
> 
> The linear array @ftrace_graph_funcs is still used in this patch.
> we still limit the number of such functions to 32?
> 
> [...]



Heh, that's right. I should probably make it a list. The array
is only used when we touch set_graph_function file.



> >  #define FTRACE_GRAPH_MAX_FUNCS		32
> >  extern int ftrace_graph_count;
> >  extern unsigned long ftrace_graph_funcs[FTRACE_GRAPH_MAX_FUNCS];
> > -
> > -static inline int ftrace_graph_addr(unsigned long addr)
> > -{
> > -	int i;
> > -
> > -	if (!ftrace_graph_count)
> > -		return 1;
> 
> Here return 1.
> 
> [...]
> > +static inline int ftrace_graph_addr(unsigned long addr)
> > +{
> > +	struct func_node *rec;
> > +	struct func_hlist *hlist;
> > +
> > +	if (!ftrace_graph_count)
> > +		return 0;
> > +
> 
> But in this patch, return 0 here, the behave will be changed.


Yeah, I've inverted the check from the tracing callback.

It seems to me that:

	if (ftrace_graph_addr(addr))

more logically means that we trace this addr. Making it
a boolean would make the things more clear perhaps?