[PATCH 0/2] dbus: Do Not Coalesce State Changed Signals

[Grant Erickson]

On 10/24/11 8:26 AM, Jouni Malinen wrote:
> On Mon, Oct 24, 2011 at 10:05:04AM -0500, Dan Williams wrote:
>> I used to have a problem with this, but I now see where it makes sense
>> for the State property alone.  Most properties *should* be coalesced to
>> reduce dbus traffic, but the State property should probably just trigger
>> an immediate emit of the interface's changed properties.  State doesn't
>> change that often so it wouldn't meaningfully increase D-Bus traffic.
> 
> What exactly are these state changes used for?

Jouni:

Connman, Flimflam and, presumably, Network Manager all use them to determine
when and what to do next in terms of setting up a Wi-Fi network connnection.

Nearly all of them key off of the COMPLETED state to initiate DHCP or to
program static addresses and routes.

> The main problem I see
> with this is that wpa_s->wpa_state is supposed to be internal data for
> wpa_supplicant and the values it has and the way they are used are
> subject to change whenever needed.. As such, I would really not want any
> external functional to depends on that for anything beyond maybe showing
> some debug information.
>
> If there is desire to actually use this type of information for taking
> some actions, it would be much safer to define a new value that will be
> generated based on internal state (including wpa_s->wpa_state) and
> define that in a way that makes it easier to maintain this in a stable
> way even if the internal implementation changes.

I think it's far too late. These state changes are baked into the core of
nearly all of the above programs. There's going to be a long path to
remediation if an alternative mechanism is proposed and required.

Coalescing aside, because the state changes seem like a highly functional
and effective way to communicate between these entities why not formalize
and codify it? If there is internal, wpas housekeeping as you suggest, I'd
suggest placing it underneath those now-very-public state changes rather
than placing something new atop them.

> There are already some horrible hacks in place for wpa_state (just see
> how WPA_IDLE is generated in Android builds) and I really do not want to
> have to consider supporting something like that with the D-Bus
> interface.

I am certainly not asking for any horrible hacks for the DBus. Aside from
this state coalescing issue, the new DBus interface to the supplicant seems
very functional and effective.

Best,

Grant