From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1age4L-0002kV-Ny for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:58:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1age4G-00014P-Ou for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:58:53 -0400 Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:35073) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1age4G-00014L-Hd for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:58:48 -0400 Received: by mail-wm0-x229.google.com with SMTP id l68so7856889wml.0 for ; Thu, 17 Mar 2016 12:58:48 -0700 (PDT) Sender: Paolo Bonzini References: <87wpp4m6n1.fsf@blackfin.pond.sub.org> <20160315133916.GM27203@stefanha-x1.localdomain> <20160315135647.GB11728@work-vm> <20160316182343.GE2012@stefanha-x1.localdomain> <20160316182748.GG2246@work-vm> <20160317112508.GG14062@stefanha-x1.localdomain> <20160317162900.GK5966@work-vm> <56EB03D0.6010209@redhat.com> From: Paolo Bonzini Message-ID: <56EB0C73.1020806@redhat.com> Date: Thu, 17 Mar 2016 20:58:43 +0100 MIME-Version: 1.0 In-Reply-To: <56EB03D0.6010209@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" , Stefan Hajnoczi Cc: =?UTF-8?Q?Llu=c3=ads_Vilanova?= , Peter Maydell , qemu-devel@nongnu.org, Markus Armbruster , Richard Henderson 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