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.
signature.asc
Description: PGP signature
