On Mon, Sep 16, 2019 at 12:41:44PM -0400, John Snow wrote: > On 9/16/19 12:40 PM, Philippe Mathieu-Daudé wrote: > > On 9/16/19 6:36 PM, Eric Blake wrote: > >> On 9/16/19 4:51 AM, Philippe Mathieu-Daudé wrote: > >>> While the tracing frawework does not forbid trailing newline in > >> > >> framework > >> > >>> events format string, using them lead to confuse output. > >>> It is the responsibility of the backend to properly end an event > >>> line. > >> > >> Why just trailing newline? Should we not forbid ALL use of newline in a > >> trace message? > > > > I thought about it and forgot to add a comment when respining. > > Yes, I think this is the right thing to enforce. > > However it requires more cleanup, affecting more subsystems, so I'd > > rather keep it for a follow-up series. > > What's the problem with using multi-line trace statements?
I agree with avoiding trailing newlines in format strings in the ./trace-events files for consistency. Although non-trailing newlines in format strings are unusual, they could make trace logs easier to read in complex cases. I don't see a reason to forbid them since we support trace backends that emit a binary log with a parsing API - there's no need to write scripts that parse the text output. > (I think I intentionally use these for AHCI in a few places.) hw/ide/ahci.c format strings do not contain newlines, so they are technically in compliance. ahci_pretty_buffer_fis() is used to generate a hex dump with newlines but it's a %s format string argument to trace_handle_reg_h2d_fis_dump() and trace_handle_cmd_fis_dump(). Stefan
signature.asc
Description: PGP signature
