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

[CEL]

Hey Vadim,

nice!
So, just writing without much of a filter:

1. Yes. GNU Radio should be a non-intrusive library. Stuff being
printed directly to stdout is a bad idea and we need to get away from
that.
2. Well, GNU Radio is used to construct pretty complex applications,
which leads to potentially a lot of log messages that are only of
interest within the GNU Radio "part" of an application that uses GNU
Radio as library (for example: Info that a buffer of a certain size was
allocated during flow graph startup), and others that are relevant to
some "business logic" of an application (e.g. network connection
dropped).
So, I think GNU Radio does need an internal logging mechanism, BUT:
That needs to be something that the application using GNU Radio can
selectively "subscribe" to.

So, what I'd say is we should get the following:

* Good GNU Radio-centralized logging, because it's such a common
requirement
* Easy ways to attach a callback to a filter on that centralized
logging instance.

The way to do that filtering could indeed be through some kind of enum
categorization. Logging frameworks do that – typically, there's
categories of severity (trace, debug, info, warning, critical, fatal or
similar). I think a string "component" and a matching filter wouldn't
be so bad a choice for a callback subscriber?

Needn't be a callback, by the way. Could also be a ZMQ sub socket.

Best regards,
Marcus

On Thu, 2019-08-29 at 00:11 +0200, Vadim Yanitskiy wrote:
> 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.
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature