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

[Stefan Hajnoczi]

On Tue, Oct 19, 2010 at 2:46 PM, Jan Kiszka <address@hidden> 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.

If there is a programmatic way of inspecting and toggling trace events
from inside an instrumented process, then yes.  If this is possible
with SystemTAP we should think about it now before QMP tracing
commands become available in a release.

Stefan