[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Our use of #include is undisciplined, and what to do ab
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it |
Date: |
Tue, 15 Mar 2016 13:39:17 +0000 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
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
signature.asc
Description: PGP signature
- [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Markus Armbruster, 2016/03/15
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Paolo Bonzini, 2016/03/15
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Peter Maydell, 2016/03/15
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it,
Stefan Hajnoczi <=
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Daniel P. Berrange, 2016/03/15
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Dr. David Alan Gilbert, 2016/03/15
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Stefan Hajnoczi, 2016/03/16
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Dr. David Alan Gilbert, 2016/03/16
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Stefan Hajnoczi, 2016/03/17
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Dr. David Alan Gilbert, 2016/03/17
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Paolo Bonzini, 2016/03/17
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Dr. David Alan Gilbert, 2016/03/17
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Paolo Bonzini, 2016/03/17
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Richard Henderson, 2016/03/17