[Spice-devel] [PATCH] log: add not fatal spice_return function

[Francois Gouget]

On Fri, 20 Nov 2015, David Jaša wrote:
[...]
> Without accompanying modification, yes. Users are taught that
> spice-server logging is controlled by SPICE_DEBUG_LEVEL environment
> variable. Glib debugging is controlled differently so if you just start
> mixing spice_* and g_* logging functions, users will start silently
> losing some debugging information...

From my perspective this is already the case, at least as far as 
developers are concerned. Anyone developing a new feature will need to 
work and use both the server and the client (or that means they're not 
doing any testing) and then they will have to use one set of functions 
on the server and another on the client, grab traces one way on the 
server and another on the client:

* Server
  spice_error() (crashes the application), spice_warning(), 
  spice_debug().
  Except server/tests/replay.c which uses g_warning() and g_debug() 
  (maybe there's a reason).

* Client
  g_error() (crashes the application), spice_printerr() (does not crash 
  the application), g_warning(), SPICE_DEBUG().
  Except spice-pulse.c which uses spice_debug() twice and channel-main.c 
  and spice-session.c which uses spice_warning().

* Spice-common
  Then there's snd_codec.c which uses spice_printerr() all over which is 
  not going to mesh with either logging systems but then since it's 
  common code and the two codebases have incompatible logging standards 
  how could it? Define a third set of macros that can be redirected 
  towards one standard or the other as apprioriate?


So I may be the first one to find this annoying and confusing but I'm 
not the first one to get confused.

Really I don't care much about whether spice_xxx() or g_xxx() is used in 
the end. But whichever way this logging discussion goes it should end up 
with a single coding and tracing standards for the client and the 
server.


-- 
Francois Gouget <fgouget at codeweavers.com>