Re: [PATCH v3 0/8] [RfC] fix tracing for modules

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

> > TODO:
> > Enabling modular tracepoints via -trace cmd line doesn't work yet.
> > Guess we need to store the list somewhere for later re-processing.
> > Error handling is tricky, specifically the "tracepoint doesn't exist"
> > error.  Suggestions / ideas are welcome.
> 
> Two ideas:
> 
> Global trace event name list
> ----------------------------
> Build *some* global information about all trace events, including
> modules, into the main QEMU binary. For example, generate an array of
> all trace event names so QEMU can always print an error if a
> non-existent trace event name is used. (This is similar to the
> trace-events-all file, which is a global list of all trace events.)
> 
> Module name prefixes
> --------------------
> Allow an optional module/group prefix like qxl:my_trace_event. When the
> user says:
> 
>   --trace qxl:my_trace_event
> 
> QEMU knows that this trace event belongs to the "qxl" module/group. It
> will not attempt to load it until the qxl module registers itself.
> 
> If "my_trace_event" doesn't exist in the qxl module:
> 1. If the qxl module is not loaded we don't hit an error. Nevermind.
> 2. When the qxl module is loaded pending events are resolved and an
>    error is printed.

Finally found the time to look at this again... 

So, we already have a "group".  Which is basically the sub-directory of
the trace-events file right now, and it seems to be mostly a build system
thing.  We get many small lists instead of one huge, but there seems to
be no other effect.  We could change that though, by giving each group
an (optional?) prefix.

There also is a probe prefix, apparently used by dtrace only.  Not sure
how to deal with that.  It prefix is qemu-<target-type>-<target-name>.
Giving qemu modules its own dtrace prefix looks sensible to me.  That
would probably something like "qemu-module-<name>".

take care,
  Gerd