Re: [PATCH v3 0/8] [RfC] fix tracing for modules

[Daniel P . Berrangé]

On Mon, Apr 12, 2021 at 03:07:59PM +0200, Gerd Hoffmann wrote:
> On Fri, Apr 09, 2021 at 02:17:13PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Apr 09, 2021 at 03:12:45PM +0200, Gerd Hoffmann wrote:
> > >   Hi,
> > > 
> > > > eg a trace point "dma_map_wait" gets mapped to probes in many
> > > > .stp files, once per target, because we need to match based on
> > > > the executable path:
> > > > 
> > > >   probe qemu.system.x86_64.dma_map_wait = 
> > > > process("/usr/libexec/qemu-system-x86_64").mark("dma_map_wait")
> > > 
> > > So, that changes with modules, we need the module name now, i.e.
> > > 
> > >     probe qemu.system.x86_64.qxl_soft_reset = \
> > >   
> > > process("/home/kraxel/qemu-install/lib/qemu/hw-display-qxl.so").mark("qxl_soft_reset")
> > > 
> > > We could repeat that in every qemu-system-$arch.stp file.
> > 
> > This would have the surprise the 'qemu.system.x86_64.qxl_soft_reset'
> > probes will fire even for qemu-system-ppc64 / qemu-system-xxxxx etc
> > because we've not restricted the scope as the original probe did.
> 
> Oh, right.
> 
> > If we can't fix that, then we must use the second option to avoid
> > the surprise IMHO
> 
> Yep.  Got that working.  Only problem is qemu-trace-stap is broken now
> and it seems there is no easy way out.  Right now qemu-trace-stap can
> simply work with a constant prefix, with that change the prefix can be
> either qemu.system.$arch or qemu.system.modules and I suspect there is
> no way around listing tracepoints to figure the correct name ...

Maybe just don't change the probe names, and declare that people have
to tell stap to filter by pid if you want exact matches

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|