From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkVni-0006I0-7K for qemu-devel@nongnu.org; Thu, 15 Sep 2016 08:30:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkVne-0001HB-Gt for qemu-devel@nongnu.org; Thu, 15 Sep 2016 08:29:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkVne-0001Gz-76 for qemu-devel@nongnu.org; Thu, 15 Sep 2016 08:29:54 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 87C858553D for ; Thu, 15 Sep 2016 12:29:51 +0000 (UTC) Date: Thu, 15 Sep 2016 13:29:48 +0100 From: "Daniel P. Berrange" Message-ID: <20160915122948.GL26068@redhat.com> Reply-To: "Daniel P. Berrange" References: <1473872922-23449-1-git-send-email-berrange@redhat.com> <1473872922-23449-6-git-send-email-berrange@redhat.com> <87vaxyukq9.fsf@fimbulvetr.bsc.es> <20160915092615.GF26068@redhat.com> <87twdhqrre.fsf@fimbulvetr.bsc.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87twdhqrre.fsf@fimbulvetr.bsc.es> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 5/6] trace: remove use of event ID enums from APIs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, Stefan Hajnoczi , Paolo Bonzini On Thu, Sep 15, 2016 at 02:20:05PM +0200, Llu=C3=ADs Vilanova wrote: > Daniel P Berrange writes: >=20 > > On Thu, Sep 15, 2016 at 01:26:06AM +0200, Llu=C3=ADs Vilanova wrote: > >> Daniel P Berrange writes: > >>=20 > >> > Since there will shortly be multiple event groups allowed, > >> > we can no longer use the TraceEventID and TraceEventVCPUID > >> > enums in the trace control APIs. There will in fact be > >> > multiple distinct enums, and the enum values will only be > >> > required to be unique per group. > >>=20 > >> This patch serves no purpose without the event group patches. > >>=20 > >> Also, AFAIR TraceEventVCPUID still needs to be a flat space (they're= all used as > >> bitmask indexes), so keeping the enum won't lose any re-compilation = benefit. > >>=20 > >> And without wanting to sound like a broken record, you can make the > >> "TRACE_${EVENTNAME}" IDs be global Event* variables (statically init= ialized in > >> "trace/generated-events.c"). That still allows using their names in = the macros, > >> avoids having a (two-level) tree of events, and eliminates the need = for the > >> Event::id member (and the trace_event_get_id() function). >=20 > > Regardless of whether its used in the public API, we still need to > > be able to assign a unique 32bit event ID to every event, because > > simpletrace currently needs to output that in its trace files. >=20 > > That said, i have been wondering if people are very tied to the > > current simple trace output format ? My ideal solution would be > > for us to dynamically assign id values to trace events when QEMU > > starts up. >=20 > > If we did this, hen in the simpletrace output file, we would have > > to insert a new record type which records an (event name, ID) > > value mapping, the first time any individual event type is > > emitted. >=20 > > Thus when simpletrace.py comes to load the trace data, instead > > of using the event ID to lookup the event directly, it would use > > the event ID to get the name from the trace data, and then lookup > > the event based on name. >=20 > A self-describing simpletrace would be so much better... Instead of reg= istering > event types the first time they're emitted, it'd be more efficient (and= probably > simpler) to register them during initialization of the trace subsystem. We can easily make it self-describing enough that you don't need to read 'trace-events' in order to parse the data. Whether we go further and also include the arg names and format strings to enable analysers to process the data, I'm not sure. We can do it incrementally I guess. THe only reason I suggested at time of first use is that we have quite a large number of events and so emitting description for all of them would take non-negligble time and possibly use significant space. I will investigate further to see if this is genuinely a problem. Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|