On Wed, Jul 01, 2020 at 05:15:01PM +0100, Daniel P. Berrangé wrote: > On Wed, Jul 01, 2020 at 05:09:06PM +0100, Stefan Hajnoczi wrote: > > On Tue, Jun 30, 2020 at 01:41:36PM +0100, Daniel P. Berrangé wrote: > > > On Fri, Jun 26, 2020 at 06:27:06PM +0200, Christophe de Dinechin wrote: > > > IMHO the whole point of having the pluggable trace backend impls, is > > > precisely that we don't have to add multiple different calls in the > > > code. A single trace_qemu_mutex_unlock() is supposed to work with > > > any backend. > > > > I think an exception is okay when the other trace backends do not offer > > equivalent functionality. > > > > Who knows if anyone other than Christophe will use this functionality, > > but it doesn't cost much to allow it. > > This patch is just an example though, suggesting this kind of usage is > expected to done in other current trace probe locations. The trace wrapper > has most of the information required already including a format string, > so I'd think it could be wired up to the generator so we don't add extra > record() statements through the codebase. At most it should require an > extra annotation in the trace-events file to take the extra parameter > for grouping, and other trace backends can ignore that.
It's true, it may be possible to put this functionality in the trace-events. Christophe: how does this differ from regular trace events and what extra information is needed? Stefan
signature.asc
Description: PGP signature