[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Do we really need logging in GNU Radio?
From: |
Andrej Rode |
Subject: |
Re: [Discuss-gnuradio] Do we really need logging in GNU Radio? |
Date: |
Thu, 29 Aug 2019 20:30:46 +0200 |
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