On 2020-07-02 at 15:47 CEST, Stefan Hajnoczi wrote... > 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.
The primary purpose of the recorder is post-mortem dumps, flight recorder style. Tracing is only a secondary benefit. Not sure if it's worth making a distinction between events you want to record and those you want to trace. (Example: You might want to record all command line options, but almost never trace them) > 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. Let me think more about integrating these features with other trace backends. See below for short-term impact. > Christophe: how does this differ from regular trace events and what > extra information is needed? - Grouping, as indicated above, mostly useful in practice to make selection of tracing topics easy (e.g. "modules") but also for real-time graphing, because typically a state change occurs in different functions, which is why I used locking as an example. - Self-documentation. Right now, the recorder back-end generates rather unhelpful help messages. - Trace buffer size. This is important to make post-mortem dumps usable if you record infrequent events alongside much higher-rate ones. For example, you may want a large buffer to record info about command-line option processing, the default 8 is definitely too small. - Support for %+s, which tells that a string is safe to print later (e.g. it is a compile-time constant, or never ever freed). - Support for custom formats, e.g. I use %v in the XL compiler for LLVM value pointers. This is a bit more advanced, but it would be neat to be able to print out QOM objects using %q :-) For the short term, what about providing trace-named wrappers around these additional recorder features? -- Cheers, Christophe de Dinechin (IRC c3d)
