Re: [Qemu-devel] Re: Static tracepoint control via trace-event

[Jan Kiszka]

Am 19.10.2010 16:12, Daniel P. Berrange wrote:
> On Tue, Oct 19, 2010 at 03:46:35PM +0200, Jan Kiszka wrote:
>> Am 19.10.2010 15:30, Stefan Hajnoczi wrote:
>>> On Tue, Oct 19, 2010 at 03:08:08PM +0200, Jan Kiszka wrote:
>>>> One quirk I stumbled over quickly was the "disable" tag in trace-events.
>>>> It confused me first as qemu starts without any tracepoint enabled by
>>>> default and I thought I had to hack the file. Then I read the doc and
>>>> wondered which exiting or future backend would come without sufficiently
>>>> fast dynamic tracepoint control. Do you have any in mind?
>>>>
>>>> Instead of making it a compile-time switch (except for simpletrace), I
>>>> would vote for declaring the simpletrace usage as the only one: disable
>>>> sets the default state of the dynamic tracepoint. That way we could use
>>>> trace-events to define a useful set of standard, moderate-impact
>>>> tracepoints that shall be on. Others will still be available once a
>>>> backend is configured, but remain off until enabled during runtime.
>>>> Anything else looks like overkill to me.
>>>
>>> The motivation for "disable" producing a nop trace event is that it
>>> allows QEMU builds without certain trace events.  A trace event cannot
>>> simply be removed by deleting its trace-events declaration since there
>>> are calls to its trace_*() function in the source tree.  So this
>>> provided a way to disable trace events before simpletrace supported
>>> enabling/disabling trace events at runtime :).
>>>
>>> Today that's no longer an issue for simpletrace and other tracing
>>> backends like LTTng UST and SystemTAP handle disabled trace events well.
>>>
>>> I agree that keeping just one meaning for the "disable" keyword is
>>> better.  Perhaps we should keep a separate "nop" keyword to build out
>>> specific trace events.
>>>
>>> When would "nop" be handy?  I think an ftrace backend is a good example.
>>> Since an ftrace marker cannot be enabled/disabled at runtime, the only
>>> way to silence unwanted trace events is to "nop" them at compile-time.
>>
>> Another to-do item is to remove the strange dependency of tracing
>> managements features on CONFIG_SIMPLE_TRACE. That way the monitor
>> commands and a to-be-added command line option to control individual
>> tracepoints could of course also be used by an ftrace backend. I bet the
>> DTrace backend will like to see this as well.
> 
> I don't see a need for any monitor commands or command line options
> for the DTrace backend, since everything is completely dynamically
> controlled based on the tracing scripts the user is running. 

Ah, it's all dynamic probing, you just need the marks. OK, was a bad
example. :)

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux