From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afpSy-0002F9-N3 for qemu-devel@nongnu.org; Tue, 15 Mar 2016 09:56:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afpSv-0003Df-FT for qemu-devel@nongnu.org; Tue, 15 Mar 2016 09:56:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afpSv-0003Da-AF for qemu-devel@nongnu.org; Tue, 15 Mar 2016 09:56:53 -0400 Date: Tue, 15 Mar 2016 13:56:47 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20160315135647.GB11728@work-vm> References: <87wpp4m6n1.fsf@blackfin.pond.sub.org> <20160315133916.GM27203@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160315133916.GM27203@stefanha-x1.localdomain> 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: Stefan Hajnoczi Cc: =?iso-8859-1?Q?Llu=EDs?= Vilanova , Peter Maydell , Markus Armbruster , qemu-devel@nongnu.org * Stefan Hajnoczi (stefanha@redhat.com) 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() ... I was going to split that the other way, and have trace-events migration/trace-events block/trace-events and then they each generate their own header. > 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!). I think the hardest part is going to be understanding all of the different tracers and the things they need to know; like that thing about simpletrace needing the single ordering; I don't know what the other backends need but I bet they've each got their own surprise. (And yes, I'd love to split them up - I tend to use traceing quite a bit in migration now and trying to do a bisect over a big migration patch series takes ages mostly because of the trace.h changes) Dave > > Any comments? > > Stefan -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK