[gst-devel] RFC: INFO and DEBUG systems

[Erik Walthinsen]

The DEBUG system is somewhat primitive right now, in that it always spews
either everything or nothing.  I'd like to fix that with output levels.  
Also, a lot of what we print out in DEBUG really should be INFO, so normal
people can see some of it.

For each mechanism, there will be two thresholds.  The first is a
compile-time #define, which sets which INFO and DEBUG lines are even
compiled in the first place.  The second is a run-time global that enables
varying numbers of the remaining INFO and DEBUG statements to actually
fire.  There will be on set of these thresholds for each of INFO and
DEBUG.

Now, the first question is whether we want to have a linear scale or a
bitfield to select which groups to display.  I'd lean towards a bitfield,
which allows you to select subsets.  This leaves us only 32 groups
however.  Some of these (probably at least 4) we'd want to leave for
plugin writers' use.

The next involves what kind of information we want the INFO and DEBUG
lines to have.  Current a debug line looks like the following:

DEBUG(1458:0)gst_bin_create_plan_func:889("pipeline"): created cothread \
0xbfe00000 (@0x8099690) for "src"
(obviously it's all one line)

The first number is the current pid, the second is the cothread number, or
-1 if cothreads aren't set up yet.  Then comes the function name and
current line number, followed by whatever string (the '("pipeline")' in
this case) that was set as the debug string for that function.  Then the
': ', and finally the string on the DEBUG line.

Obviously that's overkill for the INFO stuff.  Haven't really decided what
should be INFO yet, but probably any error or warning cases at the very
least, and various progress measure, such as the loading of a plugin,
interesting state changes, etc.

Actually, I'd like to set up INFO so it uses a function pointer.  This
function pointer would normally point to a function provided by gstreamer
that would simply do a printf or g_print, but could be replaced by a
function provided by the application.  This wouldn't just be a string
passed, it would include several pointers and other bits.  Probably:

static void gst_debug_info_handler(gint level,
gchar *file,gchar *function,gint line,gchar *debug_string,
void *curobject,void *subject,gchar *string);

The idea is that this function would piece together the appropriate debug
string.  It has pointers to the current and subject objects for the
benefit of various graphical systems and other things that want to do
something more than just print out the info.  For instance, the editor
could have a drop-down-pull-off box just for it's info messages.

The cost of this would be mitigated by the fact that the INFO call would
check the thresholds *before* calling it.

The DEBUG system could probably be set up similarly, but DEBUG should be
used at the commandline anyway, so hard-coding it to do an
fprintf(stderr,) is probably OK.

Comments?

         Erik Walthinsen <omega at cse.ogi.edu> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user