[Spice-devel] RFC: Lightweight tracing mechanism

[Jonathon Jongsma]

On Fri, 2017-06-09 at 10:59 +0200, Christophe de Dinechin wrote:
> > > What I see on the thread:
> > > - log categorization. This was similar to Djasa bug but I think
> > > he just
> > >   proposed to use domains in the glib log sense;
> 
> Punchcard analogy: “Printer sheet categorization. This was similar to
> the report that Djisktra had taken McCarthy's listing by mistake"
> 
> I thought it was a good idea to derive glib log domains automatically
> from spice-traces.def. So it’s there in the branch now. That being
> said, as noted above, glib does linear searches on domain names, so
> this does not scale well. In the long term, we may want to have a
> separate field in a structured log.


Responding only to this point for the moment: I don't think using
multiple glib logging domains is necessarily desirable. We already use
several logging domains, but the vast majority of logging statements
within each project use a single domain. In spice-server, that primary
log domain is "Spice", and in spice-gtk that domain is "GSpice". spice-
server also has some additional domains like "SpiceWorker" and
"SpiceDispatcher". spice-gtk also has GSpiceController (which isn't
really used much these days). 

The problem is that both spice-server and spice-gtk have a way to
enable debugging with an environment variable. But the code for
enabling the debugging only actually enables the primary domain. So
anything that is logged under a different domain does not get enabled.
(In fact, spice-gtk has 2 ways to enable logging with an environment
variable but one of the methods is the same one used for spice-server,
but it doesn't work since it actually enables logging for the "Spice"
domain which spice-gtk doesn't use.) I'm hoping to send some patches to
clean up this mess soon. 

But the upshot is that if we use multiple log domains we'll need to
make sure that if we enable debug, we enable all domains that we're
interested in. This will require a small maintenance burden (although
Christophe's approach probably handles it automatically). Or we could
use a single log domain and segment the different "categories" of log
messages somehow within that domain.

Jonathon