On Mon, Jul 24, 2017 at 08:02:24PM +0300, Lluís Vilanova wrote: > This series adds a basic interface to instrument tracing events and control > their tracing state. > > The instrumentation code is dynamically loaded into QEMU (either when it > starts > or later using its remote control interfaces). > > All events can be instrumented, but the instrumentable events must be > explicitly > specified at configure time. > > Signed-off-by: Lluís Vilanova <vilan...@ac.upc.edu>
Hi Lluís,
I'm concerned that the shared library interface will be abused to monkey
patch code into QEMU far beyond instrumentation use cases and/or avoid
the responsibilities of the GPL license.
Instead I suggest adding a trace backend generates calls to registered
"callback" functions:
$ cat >my-instrumentation.c
#include "trace/control.h"
static void my_cpu_in(unsigned int addr, char size, unsigned int val)
{
printf("my_cpu_in\n");
}
static void my_init(void)
{
trace_register_event_callback("cpu_in", my_cpu_in);
trace_enable_events("cpu_in");
}
trace_init(my_init);
$ ./configure --enable-trace-backends=log,callback && make -j4
This is still a clean interface that allows instrumentation code to be
kept separate from the trace event call sites.
The instrumentation code gets compiled into QEMU, but that shouldn't be
a huge burden since QEMU's Makefiles only recompile changed source
files (only the first build is slow).
Does this alternative sound reasonable to you?
Stefan
signature.asc
Description: PGP signature
