| Message ID | 20190731010933.109541-1-briannorris@chromium.org |
|---|---|
| State | Accepted |
| Headers | show |
| Series | D-Bus: demote timeout/flush messages to MSG_MSGDUMP | expand |
On Tue, Jul 30, 2019 at 06:09:33PM -0700, Brian Norris wrote: > We intentionally don't emit property-changed signals on every property > update -- for "less timing critical" messages we delay up to 5 > milliseconds waiting to see if we can batch them together. When the > timer hits, we emit the signal anyway and (potentially) log this > message. This amounts to effectively tracing every property update, > which can be quite excessive. > > Lower this to MSGDUMP, so MSG_DEBUG can remain slightly more sane. Thanks, applied.
diff --git a/wpa_supplicant/dbus/dbus_new_helpers.c b/wpa_supplicant/dbus/dbus_new_helpers.c index d80e2d402071..d9009ba85e9c 100644 --- a/wpa_supplicant/dbus/dbus_new_helpers.c +++ b/wpa_supplicant/dbus/dbus_new_helpers.c @@ -742,7 +742,7 @@ static void flush_object_timeout_handler(void *eloop_ctx, void *timeout_ctx) DBusConnection *con = eloop_ctx; struct wpa_dbus_object_desc *obj_desc = timeout_ctx; - wpa_printf(MSG_DEBUG, + wpa_printf(MSG_MSGDUMP, "dbus: %s: Timeout - sending changed properties of object %s", __func__, obj_desc->path); wpa_dbus_flush_object_changed_properties(con, obj_desc->path);
We intentionally don't emit property-changed signals on every property update -- for "less timing critical" messages we delay up to 5 milliseconds waiting to see if we can batch them together. When the timer hits, we emit the signal anyway and (potentially) log this message. This amounts to effectively tracing every property update, which can be quite excessive. Lower this to MSGDUMP, so MSG_DEBUG can remain slightly more sane. Signed-off-by: Brian Norris <briannorris@chromium.org> --- wpa_supplicant/dbus/dbus_new_helpers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)