Pierre Labastie wrote:
On 14/10/2017 07:06, Bruce Dubbs wrote:
William Harrington wrote:
On Fri, 13 Oct 2017 14:22:29 -0500
Bruce Dubbs <[email protected]> wrote:
This patch should change nothing unless the environment variable
GLIB_LOG_LEVEL is set. The values are numeric:
[...]
Is not G_MESSAGES_DEBUG not enough?
https://developer.gnome.org/glib/2.54/glib-running.html
I don't think so. From the url:
"G_MESSAGES_DEBUG. A space-separated list of log domains for which
informational and debug messages should be printed. By default, these messages
are not printed. You can also use the special value all. This environment
variable only affects the default log handler, g_log_default_handler()."
First of all, it is not clear to me what a 'log domain' is.
Second, it mentions info and debug messages, but not warning or notice
messages. My problem is seeing tons of warning messages:
(qemu:7756): Gtk-WARNING **: Allocating size to GtkScrollbar 0x90b16062c0
without calling gtk_widget_get_preferred_width/height(). How does the code
know the size to allocate?
Hi,
I think this patch is not at the right level in the code: glib is a library to
be used by other applications, and those applications are responsible for (a)
defining the log handler and (b) sending the log messages by using various
procedures such as "g_log{,v}", or "g_log_structured{,_array}". There are
wrappers ("g_message", "g_warning", etc) around those procedures. Those
procedures accept an input parameter "log_domain", which is a string which may
be used in the log message. In the default handler, "log_domain" is printed
before the log level, which means it is "Gtk" in the example above. Note that
G_MESSAGE_DEBUG allows to print messages for more log levels, but cannot be
used to filter messages out.
The procedures in (b) use the handler from (a). If the application has not
defined a handler, a default handler is used: "g_log_default_handler", which
in turn calls "g_log_writer_default". Note that it seems [1] that if journald
is present, "g_log_writer_default" writes to it, while if it is not present,
it writes to stdout or stderr (depending on the log level). So again a systemd
issue
The patch you propose modifies g_log{,_structured}, so that it blocks unwanted
messages, even if an application has defined its own log handler. If the
application handler implements some sort of filter too, that may conflict with
yours. I doubt upstream would accept that.
So the patch should be in the default handler "g_log_writer_default": as
stated in [1], "Distributors of GLib may modify this function to impose their
own (documented) platform-specific log writing policies." So I'd say this is
the right place to propose some modification to upstream.
Thank you for that analysis. Looking at the message flow, it would seem
that this function is perhaps the lowest level:
static FILE *
log_level_to_file (GLogLevelFlags log_level)
{
if (log_level & (G_LOG_LEVEL_ERROR | G_LOG_LEVEL_CRITICAL |
G_LOG_LEVEL_WARNING | G_LOG_LEVEL_MESSAGE))
return stderr;
else
return stdout;
}
It is called by g_log_writer_standard_streams() which in turn does
_g_fprintf (stream, "%s\n", out);
It is also called by _g_log_writer_fallback();
The issue is to decide what we want to do and how to do it. What I want
is to just suppress messages to either stdout or stderr. To do this in
log_level_to_file(), I would need to return fopen( "/dev/null", "w");
That is too much overhead. Better to do it before the call to
log_level_to_file().
I suppose the call to my function :
if ( skip_message( log_level ) ) return G_LOG_WRITER_HANDLED;
could be added right before the two calls to log_level_to_file().
Note that we DO handle the message by explicitly not printing out the message.
All this is because glib does not implement a generalized filter to enable
the user to control these messages. Each package that uses glib must do
that and in many cases, they don't use the correct (e.g. debug) level.
Both debug and info levels are not printed by default.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
