Re: [PATCH v2 3/3] trace: Example of "centralized" recorder tracing

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]