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 anyway. 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 events). Stefan
signature.asc
Description: PGP signature
