On Tue, Mar 15, 2016 at 10:29:06AM +0100, Markus Armbruster wrote:
> Stefan cc'ed because tracing is part of the problem.  Search for
> "tracers".

Thanks for bringing up the generated tracing headers.  David Gilbert and
I discussed splitting them up a few months ago.  I'll summarize the
problem and we can think about solutions:

trace.h includes generated-tracers.h and generated-events.h.  These
files are generated from scripts/tracetool.py.  The contents of the
files depends on the configured --enable-trace-backends= list (log,
simple, ftrace, dtrace, ust).

Idealy ./trace-events would have "sections" so that multiple files are
generated:

  # section virtio-blk
  foo() ...

  # section memory
  bar() ...

This would put trace_foo() in generated-tracers-virtio-blk.h and
trace_bar() in generated-tracers-memory.h.  Source files using tracing
would need to include headers for relevant sections.

This way we can narrow the scope of tracing headers and prevent global
recompilation.

The fly in the ointment is that trace/control.h defines enum
TraceEventID, a global numbering of all trace events.  The enum is used
in trace/contro.h APIs and also in the simpletrace file format.

If ./trace-event is modified the numbering of trace events could change.
This would require global recompilation :(.

So in order to avoid global recompilation we need to eliminate enum
TraceEventID.  Perhaps it's possible to use TraceEvent* instead of
TraceEventID.  For the simpletrace backend we would continue to use a
global ordering but that only affects generated-tracers.c and not header
files (thankfully!).

Any comments?

Stefan