Re: [Qemu-devel] [RFC][PATCH v3 00/24] instrument: Let the user wrap/override specific event tracing routines

[Stefan Hajnoczi]

On Sun, Apr 21, 2013 at 09:11:30PM +0200, Lluís Vilanova wrote:
> TODO: Operations 'instr_load' and 'instr_unload' are not thread safe.
>       (qemu_cpu_kick?)
> 
> TODO: Do cmdline actions have to be implemented on top of QMP routines?
> 
> TODO: HMP and QMP interfaces only accept one argument to "instr-load".
> 
> TODO: Replace programmatic 'InstrLoadError' in favour of QAPI's 
> 'InstrLoadCode'?
>       (harder to find using code navigation tools, as it's auto-generated; but
>       provides a single point to manage the enumeration values, which is less
>       error-prone)
> 
> 
> The whole set of patch series is available at:
>   https://projects.gso.ac.upc.edu/projects/qemu-dbi
> 
> Adds the "instrument" event property to declare which tracing events in QEMU
> must be instrumentable. Still, in case the user only wants to wrap around the
> tracing events, the original tracing implementation is accessible through the
> appropriate routines.
> 
> The instrumentation can be performed either through a dynamically-loaded 
> library
> or through user-provided code that is compiled into QEMU itself (useful when
> instrumenting high-frequency events, as the fast-path of the instrumentation 
> can
> be inlined into QEMU).
> 
> As a side-effect this series adds an API for the instrumentation code to have
> some basic interaction with QEMU.
> 
> See the documentation added in the first patch for more information.
> 
> Signed-off-by: Lluís Vilanova <address@hidden>
> ---

If I understand correctly this series allows trace events to be exported
as a shared library API.  It can be used with instrumentation libraries
(shared objects), which avoids rebuilding QEMU for each instrumentation
set.

I'm skeptical of the effort required to do this (and maintain it) when
it's easy to keep several git branches - one for each instrumentation
set - and rebuild.

Trace events are not an API.  They are not stable.  Therefore these
dynamic instrumentation libraries would be broken when QEMU changes.

Maybe I don't understand the application well enough to see the benefit?

Stefan