qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-2.8 v1 60/60] trace: update docs to reflect


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH for-2.8 v1 60/60] trace: update docs to reflect new code generation approach
Date: Wed, 14 Sep 2016 13:34:47 +0100
User-agent: Mutt/1.7.0 (2016-08-17)

On Fri, Sep 02, 2016 at 05:24:04PM -0400, Stefan Hajnoczi wrote:
> On Thu, Aug 11, 2016 at 12:11:06PM +0200, Lluís Vilanova wrote:
> > Daniel P Berrange writes:
> > 
> > > On Wed, Aug 10, 2016 at 06:11:24PM +0200, Lluís Vilanova wrote:
> > >> Daniel P Berrange writes:
> > >> 
> > >> > On Wed, Aug 10, 2016 at 04:33:47PM +0200, Lluís Vilanova wrote:
> > >> >> Daniel P Berrange writes:
> > [...]
> > >> >> For example, first we concatenate /trace-events, /io/trace-events and
> > >> >> /hw/usb/trace-events into /trace-events-all to produce:
> > >> >> 
> > >> >> @group core
> > >> >> @dir /
> > >> >> # contents of /trace-events
> > >> >> @group io
> > >> >> @dir /io
> > >> >> # contents of /io/trace-events
> > >> >> @group hw_usb
> > >> >> @dir /hw/usb
> > >> >> # contents of /hw/usb/trace-events
> > >> >> 
> > >> >> Then we can use /trace-events-all to generate all the per-directory 
> > >> >> trace.h
> > >> >> files while ensuring a perfectly flat event identifier space (a single
> > >> >> generated-events.c is used).
> > >> >> 
> > >> >> This should minimize changes to tracing code and avoid further 
> > >> >> restrictions
> > >> >> (like the "top-level vcpu" one).
> > >> 
> > >> > That means when any individual trace file is changed, we re-generate 
> > >> > the
> > >> > world, which is exactly what this series is designed to avoid.
> > >> 
> > >> Nope. We re-generate /trace-events-all, but each individual file 
> > >> generated
> > >> afterwards (taken from the "@dir" directive) will change only if its new
> > >> contents do (the Makefile uses cmp to check if files need updating from 
> > >> their
> > >> corresponding timestamp file).
> > 
> > > The contents will still need to change too if we have a global numbering
> > > space as your suggestion requires. The event groups are the only way to
> > > avoid that.
> > 
> > Aha, that's true. I didn't think of that, sorry.
> 
> Nevertheless, I agree that @id_offset() should be eliminated to avoid
> collisions and manual effort when trace-events files are added.

I think I have a workable solution to eliminate this. During build I'll
create a file 'trace-event-file-list' which contains a list of paths to
'trace-event' files in the tree. We'll then use the line number in this
file as the id offset for events. The generated $SUBDIR/trace.h file
will depend on trace-event-file-list.

So we'll have fully automatic numbering for each trace-event file and
will only get a full rebuild if someone adds a completely new trace-event
file, which is acceptable.

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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]