From: James Prestwood <prestwoj@gmail.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: iwd@lists.linux.dev
Subject: Re: [RFC 2/5] station: use l_notice for station_debug_event, allow arguments
Date: Wed, 14 Feb 2024 12:02:45 -0800 [thread overview]
Message-ID: <95c6f271-2f18-4381-b0d9-b31e86741700@gmail.com> (raw)
In-Reply-To: <708401D3-CE90-4A7C-9008-F64904877BC9@holtmann.org>
Hi Marcel,
On 2/14/24 11:46 AM, Marcel Holtmann wrote:
> Hi James,
>
>> For anyone debugging or trying to identify network infrastructure
>> problems the IWD DBus API isn't all that useful and ultimately
>> requires going through debug logs to figure out exactly what
>> happened. Having a concise set of debug logs containing only
>> relavent information would be very useful. In addition, having
>> some kind of syntax for these logs to be parsed by tooling could
>> automate these tasks.
>>
>> This is being done, starting with station, by using l_notice. The
>> use of l_notice in IWD will be strictly for the type of messages
>> described above. Modules using l_notice should follow the same
>> log format so tooling can parse the messages generically. The
>> format should be zero or more comma-separated key value pairs,
>> starting with "event: <event name>".
>>
>> station_debug_event is being modified to use l_notice as most of
>> the events are useful for debugging. This was modified slightly
>> to allow arguments to be passed in order to provide extra
>> information if available.
>> ---
>> src/station.c | 25 +++++++++++++++----------
>> 1 file changed, 15 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/station.c b/src/station.c
>> index ea505ca2..a097174e 100644
>> --- a/src/station.c
>> +++ b/src/station.c
>> @@ -215,15 +215,13 @@ static bool station_is_roaming(struct station *station)
>> station->state == STATION_STATE_FW_ROAMING;
>> }
>>
>> -static bool station_debug_event(struct station *station, const char *name)
>> +static bool station_emit_event(struct station *station, const char *name)
>> {
>> struct l_dbus_message *signal;
>>
>> if (!iwd_is_developer_mode())
>> return true;
>>
>> - l_debug("StationDebug.Event(%s)", name);
>> -
>> signal = l_dbus_message_new_signal(dbus_get_bus(),
>> netdev_get_path(station->netdev),
>> IWD_STATION_DEBUG_INTERFACE, "Event");
>> @@ -233,6 +231,12 @@ static bool station_debug_event(struct station *station, const char *name)
>> return l_dbus_send(dbus_get_bus(), signal) != 0;
>> }
>>
>> +#define station_debug_event(station, name, fmt, ...) \
>> +({ \
>> + l_notice("event: %s, " fmt, name, ##__VA_ARGS__); \
>> + station_emit_event(station, name); \
>> +})
>> +
>> static void station_property_set_scanning(struct station *station,
>> bool scanning)
>> {
>> @@ -1565,7 +1569,7 @@ static void station_enter_state(struct station *station,
>> station_state_to_string(station->state),
>> station_state_to_string(state));
>>
>> - station_debug_event(station, station_state_to_string(state));
>> + station_debug_event(station, station_state_to_string(state), "");
>>
>> disconnected = !station_is_busy(station);
>>
>> @@ -2351,13 +2355,14 @@ static bool station_ft_work_ready(struct wiphy_radio_work_item *item)
>> l_queue_insert(station->roam_bss_list, rbss,
>> roam_bss_rank_compare, NULL);
>>
>> - station_debug_event(station, "ft-fallback-to-reassoc");
>> + station_debug_event(station, "ft-fallback-to-reassoc", "");
>>
>> station_transition_start(station);
>> l_steal_ptr(rbss);
>> break;
>> case -ENOENT:
>> - station_debug_event(station, "ft-roam-failed");
>> + station_debug_event(station, "ft-roam-failed",
>> + "reason: authentication timeout");
>> try_next:
>> station_transition_start(station);
>> break;
>> @@ -2560,7 +2565,7 @@ static void station_roam_scan_triggered(int err, void *user_data)
>> return;
>> }
>>
>> - station_debug_event(station, "roam-scan-triggered");
>> + station_debug_event(station, "roam-scan-triggered", "");
> this is really awful.
>
> Lets have the event / state name as enum or something so that it is const.
>
> And then having the empty “” all the time is insane. That is horrible API and in 2 month you wonder what the “” is for. So let’s not do that. Rather have station_debug_event and station_debug_event_printf.
So, I can separate station_debug_event from this l_notice stuff, it just
fit nicely together from the standpoint of these "debug events" are
useful, and I didn't want have repeated calls like:
station_debug_event(...)
l_notice(...)
The extra argument was to avoid manually parsing some arbitrary number
of args by always passing in a format string but we could avoid this by
separating the two and making them independent calls.
>
> Or just shorten it into STATION_DBG_EVT and STATION_DEBUG_EVT_PRINTF. I mean, the assumption is that this code is purely for debug and has not functional meaning. So if left out, the code will do the right thing. If not, then never ever call it debug.
>
> Regards
>
> Marcel
>
next prev parent reply other threads:[~2024-02-14 20:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-14 19:37 [RFC 0/5] Using l_notice for low level IWD state information James Prestwood
2024-02-14 19:37 ` [RFC 1/5] main: add runtime flag for setting the logger James Prestwood
2024-02-14 19:37 ` [RFC 2/5] station: use l_notice for station_debug_event, allow arguments James Prestwood
2024-02-14 19:46 ` Marcel Holtmann
2024-02-14 20:02 ` James Prestwood [this message]
2024-02-14 20:11 ` Marcel Holtmann
2024-02-14 19:37 ` [RFC 3/5] station: add additional station_debug_event's James Prestwood
2024-02-14 19:37 ` [RFC 4/5] netdev: add notice events for connection timeouts James Prestwood
2024-02-14 19:37 ` [RFC 5/5] doc: document use of l_log APIs James Prestwood
2024-02-14 19:49 ` Marcel Holtmann
2024-02-14 19:55 ` James Prestwood
2024-02-14 20:12 ` Marcel Holtmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=95c6f271-2f18-4381-b0d9-b31e86741700@gmail.com \
--to=prestwoj@gmail.com \
--cc=iwd@lists.linux.dev \
--cc=marcel@holtmann.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox