[Spice-devel] [spice-server v4 5/5] Change some spice_printerr() to spice_debug()

[Jonathon Jongsma]

On Wed, 2017-02-15 at 16:34 +0100, Christophe de Dinechin wrote:
> > On 15 Feb 2017, at 12:45, Frediano Ziglio <fziglio at redhat.com>
> > wrote:
> > 
> > > @@ -134,7 +134,7 @@ static void
> > > red_qxl_display_migrate(RedChannelClient
> > > *rcc)
> > >     }
> > >     g_object_get(channel, "channel-type", &type, "id", &id,
> > > NULL);
> > >     dispatcher = (Dispatcher
> > > *)g_object_get_data(G_OBJECT(channel),
> > >     "dispatcher");
> > > -    spice_printerr("channel type %u id %u", type, id);
> > > +    spice_debug("channel type %u id %u", type, id);
> > >     payload.rcc = rcc;
> > >     dispatcher_send_message(dispatcher,
> > >                             RED_WORKER_MESSAGE_DISPLAY_MIGRATE,
> > 
> > Looks like there's lot of debugging on migration.
> > Like we are not really sure the code is working.
> 
> Maybe someone once needed a lot of debug information, and kept it
> around in case things start going south. That probably means we have
> annotations that may end up being annoying for everybody debugging
> anything else than migration.
> 
> This leads me to a meta-question: would it make sense to add “traces”
> to the spice code, i.e. dynamically configurable flags that activate
> sets of related printf. Today, we have spice “errors”, “debug” or
> “info”, but we could have finer-grained logging for specific topics,
> e.g. migration or encoding.
> 
> In Tao3D, there are topical traces like this declared here: https://g
> ithub.com/c3d/tao-3D/blob/master/tao/traces.tbl. If you want to have
> the “font” trace activated, you simply run the program with the
> -tfont option, or set a flag from within a debugger. Within the code,
> traces are tested with something like if (TRACE(font)), e.g.
> https://github.com/c3d/tao-3D/blob/master/tao/font.cpp#L102. A
> special form a printf takes a trace name as input, e.g. we could have
> spice_trace(font, …). The cost of a not-taken trace is a mere not-
> taken if statement with a bit-field read (one trace = one bit), so
> the overhead is really low. This means that you can leave verbose
> debug information in place in case it helps addressing a specific
> kind of debug situation.
> 
> Would anything like this make sense for spice?

Victor was playing around with something like this a while back:
https://lists.freedesktop.org/archives/spice-devel/2016-January/025293.
html

I wasn't totally convinced that something more complicated like that
was necessary, but hadn't come to a definitive conclusion. But there
was not much discussion from others at the time.

Jonathon