GNOME Bugzilla – Bug 733188
review debugging env vars
Last modified: 2018-11-03 12:21:20 UTC
Current debug-log env vars GST_DEBUG_FILE (defaults to stderr) when not set log to stderr, when set points to path for the debug log GST_DEBUG_COLOR_MODE (defaults to color) (deprecated) when set use ansi color codes, otherwise plain text GST_DEBUG_NO_COLOR ("on", "auto", "off", "disable", "unix") on = auto: platform specific color codes off = disabled: no color codes unix = force ansi Proposed env vars GST_DEBUG_CHANNEL (defaults to stderr) stderr fd://stderr, fd://stdout file:///path/to/file (or /path/to/file , file) tcp://<ip>:<port> (or just <ip>:<port>) mem://<size> Log to the given channel. Alternative names GST_DEBUG_{STREAM,OUT,METHOD,....} GST_DEBUG_FORMAT (default to text/auto-color) text/plain (plain text) text/auto-color (platform specific color codes) text/ansi (ansi color coded) binary/ctf (see babeltrace (Common Trace Format (CTF), e.g. used by lttng) These could be sort-of mime-types. We also could discuss if we just want to have one at a time, or even allow multiple pairs. The ater makes it tricky for the variables though. Another alternative would be to merge CHANNEL+FORMAT as a uri: GST_DEBUG_OUT=fd://stderr#format=text/plain&option1=value&option2=value
Created attachment 286047 [details] [review] avoid global variable for log_file As a preparation to refactor some code in gstinfo... The only concern i have is when calling gst_debug_add_log_function(NULL, user_data, cleanup) we will implicity use gst_debug_log_default() again, but now can't ensure user_data to point to the log_file. I can add a destry_notify function and close the logfile. In addition the code in gst_debug_add_log_function() could also run throught he codepath from _priv_gst_debug_init() to setup a default user_data if that is NULL as well. Personally I think its overkill :) Thoughts?
FWIW, I know multiple vendors which have added public API to change the file at run-time (not that I'm really sure why/where that is useful), they will be unhappy to remove the global var ;) (Not that it's a reason not to do it, just saying)
Tim, thanks for the headsup. If you already know them, maybe you can inquire for their user-cases. This might be helpful for this discussion. The next thing I want to do, is to chop gst_debug_log_default() into separate functions for each color mode, so that we don't check the color_mode for each logging call (and mainly to remove the #ifs and ifs from the code). It would be nice to be explicit on what is set once at start and must not be changed and what things can be change during runtime of an application. Setting the color-mode and the log-output target is something that I would setup once when starting and be done with it.
commit a528dadb9800fd3b21b60c4b3cd707e4616aed41 Author: Stefan Sauer <ensonic@users.sf.net> Date: Fri Sep 12 14:42:23 2014 +0200 info: avoid global variable for log_file Use user_data to pass the log_file handle to the logger-function. If one wants to change the log target (e.g. GST_DEBUG_FILE), simply call gst_debug_remove_log_function() and re-add the handler with the new log-target using gst_debug_add_log_function ().
Hello, I was wondering if the plans for implementing the option of sending the tracing to a file or a socket have been abandoned or is it still under works?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/64.