Re: [Discuss-gnuradio] Do we really need logging in GNU Radio?
Hi,
> > 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).
I plead guilty. It was me.
> > 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.
This idea was especially valuable as blocks/objects/modules could keep
the logging messages in a binary format. Meaning that for each
event/block there could be a struct which contains information and
instead of serializing/stringifying every event logged the information
could stay in a binary/original format until it really needs to be
converted to a string. (Which is actually how the python logging
library handles string formating as well).
I thought about something like passing a
"event_severity, event_component, event_data_t, event_data_fmt" with
the last argument being a function pointer which can convert
event_data_t to string. For simple logging messages with static content
this could just be a static string, but for dynamic content this could
convert all sorts of information to a printable string (if needed).
Obviously I'm not going to implement this, just my 2 cents where this
idea originated.
Cheers
Andrej
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Do we really need logging in GNU Radio?
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
[Discuss-gnuradio] Do we really need logging in GNU Radio?
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
