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

[Paolo Bonzini]

On 17/03/2016 20:21, Paolo Bonzini wrote:
> On 17/03/2016 17:29, Dr. David Alan Gilbert wrote:
>> OK, so I see TraceEvent has a TraceEventID field; so yes that works easily;
>> it turns out to be a little more expensive though since what was a:
>>
>>    trace_events_dstate[id]
>>
>> is now
>>    trace_events_dstate[te->id]
> 
> That however makes you waste a lot of cache on trace_events_dstate
> (commit 585ec72, "trace: track enabled events in a separate array",
> 2016-02-03).
> 
> Perhaps we get the linker to do compute the id, for example by using a
> separate data section and then use te-&te_first to compute the id...
> Richard, do you have ideas on how to do this in a reasonably portable
> manner?

Dave and I actually got to a much better design on IRC.

1) since the .h files will be per-directory, make the dstate array per
directory (e.g. trace_events_dstate_migration[])

2) changes must have no effect on unrelated .h files, but we can keep a
global .c file.  Instead of using trace_events_dstate[te->id], we can
store a pointer directly in te, e.g. ".p_dstate =
&trace_events_dstate_migration[23]" and then *(te->p_dstate).  The
global .c file can also store mappings from local id to global id, so
that the global id can be retrieved with "trace_events_ids_migration[23]".

Processing trace-events would remain a global process, but unchanged .h
files would not be changed on disk and would not trigger the world.
Splitting the input to tracetool becomes a separate task from splitting
its output, and could be achieved simply by introducing include directives.

Paolo