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.

Regards,
Pierre


[1] https://developer.gnome.org/glib/stable/glib-Message-Logging.html


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to