[Top][All Lists]

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

Re: [Qemu-devel] [Qemu-block] [PATCH 02/17] trace: Show blockjob actions

From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 02/17] trace: Show blockjob actions via bytes, not sectors
Date: Wed, 19 Apr 2017 10:12:16 +0100
User-agent: Mutt/1.8.0 (2017-02-23)

On Mon, Apr 17, 2017 at 02:55:53PM -0500, Eric Blake wrote:
> On 04/17/2017 02:18 PM, John Snow wrote:
> >> @@ -346,13 +349,15 @@ static uint64_t coroutine_fn 
> >> mirror_iteration(MirrorBlockJob *s)
> >>  backup_do_cow_skip(void *job, int64_t start) "job %p start %"PRId64
> >>  backup_do_cow_process(void *job, int64_t start) "job %p start %"PRId64
> >>  backup_do_cow_read_fail(void *job, int64_t start, int ret) "job %p start 
> >> %"PRId64" ret %d"
> > 
> > I guess these three were "cluster" based, but you didn't need to change
> > anything to assert them as byte-based.
> > 
> >>
> > 
> > Under the assumption that it's okay to change tracing output without
> > being able to differentiate between new and old output:
> I'll leave that to Stefan's discretion as trace maintainer, but my
> thoughts are that tracing is for debugging purposes, and as long as you
> know what binary you are debugging, you can figure out what the trace
> message meant by referring back to the source that generated that binary.

That's okay.  Trace events are not a stable interface.  Most trace
events are low-level and require access to the corresponding source tree

The only exception is that tools in scripts/ may need to be updated when
trace events change (e.g. scripts to graph or analyze specific trace


Attachment: signature.asc
Description: PGP signature

reply via email to

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