Re: [PATCH] tracing/filters: allow event filters to be set onlywhen not tracing

[Paul E. McKenney]

On Sat, Apr 04, 2009 at 11:49:30AM -0400, Steven Rostedt wrote:
> On Sat, 4 Apr 2009, Tom Zanussi wrote:
> > 
> > Hmm, after reading Paul's replies, it sounds like this approach might be
> > more trouble than it's worth.  Maybe going back to the idea of
> > temporarily stopping/starting tracing would be a better idea, but with a
> > little more heavyweight version of the current 'quick' tracing
> > start/stop (that would prevent entering the tracing functions (and ththe
> > filter_check_discard()).
> 
> Actually, I forgot what the general problem we are avoiding here with the
> RCU locks. Could you explain that again. Just so that I can get a better
> idea without having to read between the lines of the previous messages in 
> this thread.

I would be interested in hearing this as well.

							Thanx, Paul

> > I was thinking it would be something like:
> > 
> > stop_tracing();
> > current_tracer->stop(); /* unregister tracepoints, etc */
> > 
> > remove filter
> > 
> > current_tracer->start(); /* reregister tracepoints, etc */
> > start_tracing();
> 
> This use to be the way start and stop worked, but I'm trying to
> make them more light weight. I've been wanting start/stop to be called
> by start_tracing() and stop_tracing() and those should be able to be 
> called in any context. But registering and unregistering tracepoints calls 
> mutexes, which can not be done in atomic context.
> 
> There are still some tracers that have start/stop using sleeping code, but 
> in the long run I want the tracers start/stop functions to be light.
> 
> 
> > 
> > The struct tracer comments suggest that the stop()/start()
> > ops are meant for pausing, I'd guess for things like this, but some of
> > the tracers don't implement them.
> 
> Yeah, They should, but leaving out the start/stop functions, is just
> the tracers way of saying, I don't need to pause. :-/
> 
> > 
> > For the events in the event tracer, it would be something like:
> > 
> > stop_tracing();
> > call->unregfunc(); /* unregister tracepoint */
> > 
> > remove filter
> > 
> > call->regfunc(); /* reregister tracepoint */
> > start_tracing();
> > 
> > If that makes sense, I can try it that way instead.
> > 
> 
> I'll comment about this if I get that explanation of the problem again ;-)
> 
> -- Steve
> 
--
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/