[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+jqyFCGAtpTKpOsMwFnbDVuUC0O5jcEG+kRG3NFC8+8OznVmw@mail.gmail.com>
Date: Sun, 25 Mar 2012 23:41:49 +0530
From: Rajesh Bhagat <rajesh.lnx@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] ftrace: fix dynamic ftrace filter reset issue
Hi Steven,
Thanks a lot for you feedback.
- Rajesh
On Sat, Mar 24, 2012 at 7:25 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> On Sat, 2012-03-24 at 09:47 +0530, Rajesh Bhagat wrote:
>> Hi Steven,
>>
>> Thanks for the reply.
>>
>> I was wondering, why would a user reset the trace __explicitly__
>> without even using it.
>> That is why i created a patch for it.
>>
>> >> /debug/tracing # echo function > current_tracer
> ^
> |
> user starts using tracer
>
>> >> /debug/tracing # cat trace <------ Not performed
>> >> /debug/tracing # echo schedule > set_ftrace_filter
>> >> /debug/tracing # echo function > current_trace
>> >> /debug/tracing # cat trace <------- Only this is performed
>
> Why the first "echo function"? That means you just started using the
> tracer. You can (and should) do:
>
> # echo schedule > set_ftrace_filter
> # echo function > current_tracer
>
> This IIRC is the documented way of using it.
>
> That said, I may consider taking the patch, as another way of resetting
> the tracer. I have to see what workflows it will affect first.
>
> -- Steve
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists