[Spice-devel] RFC: Lightweight tracing mechanism

[Marc-André Lureau]

Hi

----- Original Message -----
> 
> 
> 
> 
> On 23 May 2017, at 12:55, Victor Toso < victortoso at redhat.com > wrote:
> 
> On Tue, May 23, 2017 at 11:51:01AM +0200, Christophe Fergeau wrote:
> 
> 
> 
> or something like glib (SPICE_XXX_DEBUG=alignment:foo:bar)
> 
> Just to point out that we have a bug for this [0] and IMHO it would be
> the best approach but it would take some effort to have it besides the
> glib that we would need is 2.50 (current required is 2.36)
> [0] https://bugs.freedesktop.org/show_bug.cgi?id=91838
> 
> Pavel also recently commented on having some trouble with --spice-debug and
> SPICE_DEBUG and…
> 
> For what it’s worth, I’ve implemented in several of my own projects a low-key
> tracing facility which for Spice would basically look like this:
> 
> https://github.com/c3d/spice-common/compare/cast-warnings...c3d:traces
> https://github.com/c3d/spice-gtk/compare/cast-warnings...c3d:traces
> 
> Specifically:
> 
> - Define available traces in spice-traces.def file, e.g.:
> 
> // SPICE_TRACE(name, default_value, info)
> SPICE_TRACE(foo, false, “Talk about foo")
> SPICE_TRACE(bar, true, “A bar is a good thing, enabled by default")
> #undef SPICE_TRACE
> 
> - Declare a structure holding one bit per trace flag, as follows:
> 
> extern struct spice_traces {
> #define SPICE_TRACE(name, init, info) bool name:1;
> #include “spice-traces.def”
> } spice_traces;
> 
> - Initialize it in log.c, as follows:
> 
> struct spice_traces spice_traces = {
> #define SPICE_TRACE(name, init, info) init,
> #include “spice-traces.def"
> };
> 
> - In log.c, add a function to deal with passing trace options either from
> command-line or environemnt
> 
> - In log.h, add macros to quickly test traces:
> 
> #define TRACE(name) (spice_traces.name)
> #define IFTRACE(name) if (TRACE(name))
> #define spice_trace(name, …) IFTRACE(name) spice_debug(__VA_ARGS__)
> 
> - In spice-option.c, add code to deal with testing the options.
> 
> Would you find this useful? The most difficult part being to connect that to
> existing tracing mechanisms to avoid replication of traces, while at the
> same time ensuring that the existing enabling mechanisms work as before.
> 
> 

I would rather stick to glib structured logging (and have compatibility code for glib < 2.50), or try to find a way to use qemu tracing facility (ftrace/lttng etc).

Imho any improvement to logging & tracing should go to these respective projects if possible, since they have better chances to be common & maintain & with a set of tools to help you analyze with the rest of the system.