[Spice-devel] [PATCH spice-common 0/4] RFC: add structured logging and log category

[Marc-André Lureau]

Hi

----- Original Message -----
>
> > (fwiw, I prefer the shorter version…)
> 
> Remember that the dump only shows up in case of crash.
> 
> Are you arguing problems are easier to debug with less data?

Yes, less noise, but relevant data. Saying that becuase your short version is already full of criticals, enough to start digging imho.

> > This is unrealistic, if you trace something hot, you are in a single
> > domain, or you make it use a single (sub)domain.
> 
> Any data to support that correctly wrong hypothesis?

Let's stop discussing tracing in this thread, it's going in circles. Let's be concrete, please send patches of what you want to have traced.

> 
> > 
> >>> and Marc-André's approach has the advantage
> >>> (to me) of not needing #define MAGIC_FOO(x) ... #include "foo.defs"
> >>> which I'm not a big fan of.
> >> 
> >> That’s the trade-off for DRY (don’t repeat yourself) vs. WET (write
> >> everything twice, or we enjoy typing).
> > 
> > What I propose is to have a single definition line in most cases, there is
> > no duplication. If you need to share it in multiple units, it follows the
> > traditional C declaration/definition. And if deemed better, we can switch
> > to you #include trick, but I am against it, as it's better to declare the
> > domain where it's actually used, and do not trigger whole-codebase
> > compilation on change.
> 
> And I could be swayed to trade off some performance for putting it in a
> library. If it’s in glib, then it’s worth the trade off. If we want to save
> build time, then we should look at autoconf. When switching branches,
> autoreconf takes 40s, the configure script 35s, total 75s. When you change
> spice-traces.def, it takes 22s to rebuild. So you are really inventing
> problems here.

Mixing problems: configure vs build time. And it's not the speed argument that always wins, otherwise I agree we wouldn't be using autotools.