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
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
