From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afpNx-00066K-5l for qemu-devel@nongnu.org; Tue, 15 Mar 2016 09:51:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afpNt-0001EE-Ue for qemu-devel@nongnu.org; Tue, 15 Mar 2016 09:51:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afpNt-0001E7-Ow for qemu-devel@nongnu.org; Tue, 15 Mar 2016 09:51:41 -0400 Date: Tue, 15 Mar 2016 13:51:36 +0000 From: "Daniel P. Berrange" Message-ID: <20160315135136.GD3168@redhat.com> References: <87wpp4m6n1.fsf@blackfin.pond.sub.org> <20160315133916.GM27203@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org, Peter Maydell , Markus Armbruster , "Dr. David Alan Gilbert" , =?utf-8?B?TGx1w61z?= Vilanova On Tue, Mar 15, 2016 at 01:39:17PM +0000, Stefan Hajnoczi 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() ... > > 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. I'd actually like to see the trace events associated with the subsystem eg any trace events for block devices should live in block/trace-events, likewise for things like crypto/trace-events, io/trace-events, etc, etc. This would naturally lead to generating a block/trace-events.h file that only contained the block trace point definitions. As well as simplifying compilation deps, it means the trace-events file changes get associated with correct people for get_maintainer.pl usage, and we reduce liklihood of merge conflicts for pull requests by getting rid of the single big file Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|