Re: SPICE logging facilities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Wed, Jul 04, 2018 at 12:29:15PM -0400, Frediano Ziglio wrote:
> > 
> > On Wed, Jul 04, 2018 at 11:38:14AM -0400, Frediano Ziglio wrote:
> > > Another question is however "Are we going to use g_critical
> > > as g_critical?". It sounds a tricky question. Let say that
> > > a new person starts to look at the code and knows GLib. He
> > > see g_critical and think "well, this by default log a
> > > critical warning and continue" but instead on Spice is
> > > always fatal.
> > 
> > Unless I am confused, g_critical() should have the usual
> > default behaviour, and spice_critical() aborts, see
> > test_spice_abort_level_g_warning and the following tests
> > https://gitlab.freedesktop.org/spice/spice-common/blob/master/tests/test-logging.c#L62
> > 
> > Christophe
> 
> But you suggested c3d to use g_critical instead of
> spice_critical, isn't it confusing?

Okay, took some time to understand why it is confusing to you.
The problem is the behavior itself, you would like to keep the
abort/assert, correct?

> Forgot about telling what I think about logging and g_XXX vs
> spice_XXX.
> I agree we should use a single API to avoid confusion but
> should be consistent, not introducing free regressions so
> spice_critical -> g_error and
> spice_return_if_fail/spice_return_val_if_fail/spice_assert ->
> g_assert (making sure it's never disabled!).

Sounds reasonable.

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Index of Archives]     [Linux Virtualization]     [Linux Virtualization]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]