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