[Discuss-gnuradio] Do we really need logging in GNU Radio?

[Vadim Yanitskiy]

Hello Marcus and GNU Radio community,

during the last congress (35c3) we have been talking about
the logging in GNU Radio. I was not thinking about this much,
until the recent discussion with another GNU Radio developer
at the CCCamp 2019 (unfortunately, I forgot his name, sorry).

That developer shared an interesting opinion that GNU Radio
should be considered as a library, thus it should not do any
logging itself. And then I came up with the following idea:

What if a GNU Radio block could have a set of events that are
being generated in some situations? Let's just look at the
Audio Source and Sink (ALSA) blocks. In case of a buffer
overrun / underrun, we do print magic 'aO' / 'aU' symbols.
That's how we currently signal that something has happened.

Instead of printing directly to stderr (or anywhere else),
we can define a value-string array of possible events:

  enum gr_audio_event_t {
    GR_AUDIO_EV_OVERRUN,
    GR_AUDIO_EV_UNDERRUN,
    GR_AUDIO_EV_FOO_BAR,
    /* other events... */
  };

  struct value_string {
    unsigned int value;
    const char *string;
  } gr_audio_events[] = {
    { GR_AUDIO_EV_OVERRUN, "Buffer overrun" },
    { GR_AUDIO_EV_UNDERRUN, "Buffer underrun" },
    { GR_AUDIO_EV_FOO_BAR, "Pretty description" },
    /* other events... */
    { 0, NULL }
  };

and give a possibility to the API user to subscribe either to
some of the events, or to all of them, so logging can be done
by the user itself, if needed. For GUI applications, the
corresponding part of UI can be updated instead.

Other blocks, such as TCP Source and Sink, could also generate
some potentially interesting events, such as connection status
(server got a new connection, client has lost connection, etc.).

I am not going to work on it, this is just an idea, which may
probably look interesting to some developers / users too.

With best regards,
Vadim Yanitskiy.