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

[Daniel P. Berrange]

On Tue, Mar 15, 2016 at 01:39:17PM +0000, Stefan Hajnoczi 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() ...
> 
> 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.

I'd actually like to see the trace events associated with the subsystem
eg any trace events for block devices should live in block/trace-events,
likewise for things like crypto/trace-events, io/trace-events, etc, etc.

This would naturally lead to generating a block/trace-events.h file that
only contained the block trace point definitions.

As well as simplifying compilation deps, it means the trace-events file
changes get associated with correct people for get_maintainer.pl usage,
and we reduce liklihood of merge conflicts for pull requests by getting
rid of the single big file

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|