Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it

[Dr. David Alan Gilbert]

* Stefan Hajnoczi (address@hidden) wrote:
> 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() ...

I was going to split that the other way, and have
  trace-events
  migration/trace-events
  block/trace-events

and then they each generate their own header.

> 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!).

I think the hardest part is going to be understanding all of the different
tracers and the things they need to know; like that thing about simpletrace
needing the single ordering;  I don't know what the other backends need
but I bet they've each got their own surprise.

(And yes, I'd love to split them up - I tend to use traceing quite a bit
in migration now and trying to do a bisect over a big migration patch
series takes ages mostly because of the trace.h changes)

Dave

> 
> Any comments?
> 
> Stefan


--
Dr. David Alan Gilbert / address@hidden / Manchester, UK