Re: [Qemu-devel] [PATCH v2 10/11] trace-state: [stderr] add support for dynamically enabling/disabling events

[Lluís]

Stefan Hajnoczi writes:

> On Tue, Apr 26, 2011 at 1:30 PM, Fabien Chouteau <address@hidden> wrote:
>> On 04/25/2011 08:10 PM, Paolo Bonzini wrote:
>>> On 04/25/2011 12:27 PM, Lluís wrote:
>>>> But in any case, I'm still not sure if stderr should have programatic
>>>> tracing state controls.
>>> 
>>> Yes, please, stderr is even more useful than simple when you're using it 
>>> under gdb.
>> 
>> Agreed, trace control seems really useful with stderr, and we should be able 
>> to
>> do this in a generic way (shared by simple and stderr backends).

> The commonality between stderr and simple is having a set of trace
> events with on/off states.  Generating trace.h/trace.c is mostly
> common.  Toggling trace event states from the monitor as well as
> -trace events=<file> are common.

> The simple backend additionally allows setting and flushing the output
> file.  It also supports dumping the trace buffer.

Ok, what I was thinking about long time ago is providing some generic
"trace_*" interface for the common cmdline and monitor commands to use
(basically list event names and query or change their dynamic state,
which is the only common part on all backends).

With this, every backend is responsible of providing a suitable
implementation. If no implementation is provided, a default one will be
used that simply results in qemu erroring out when any of these
functionalities is invoked.

I think this was already discussed, and the idea was rejected because it
seemed too verbose for qemu to implement tracepoint controls when other
external tools already exist for such backends (e.g., ust). Maybe
providing the default implementation on the previous paragraph would
solve the issues.


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth