[PATCH]Persist log_level in wpa_supplicant

[Jouni Malinen]

On Sat, Mar 28, 2015 at 05:26:13PM +0100, Ola Olsson wrote:
> Attached is a patch that persists the log_level in wpa_supplicant. The
> solution might not be the best but I was not able to find any better
> solution unfortunately.

This would break existing use cases and as such, I cannot really apply
this.

> Every time the supplicant is started, it uses the log level
> that was used the last time the config file was saved.

This is the part that breaks existing behavior. In addition, it would be
quite unclear what to do if there is conflicting log level configuration
in configuration files when multiple interfaces are used. Debug log
verbosity is a global state of the wpa_supplicant process while the
configuration file is specific to each instance of an interface within
such process.

> Before this patch, there were two options to change debug level
> 
> 1) Statically at start up using args "-d" or "-q". Particularly
> in Android, this is cumbersome since I need to change the boot
> image to alter this variable.

Wouldn't the correct way of handling that be by modifying Android
to allow debugging level to be configurable either through a command
line change or a control interface call from the framework? Recently,
means for configuring "Wi-Fi Verbose Logging" was introduced.. That (or
extension of it) should really be able to cover this as well.

> 2) Runtime via wpa_cli. This is a good way but hard to get right
> timing if I need to log during the startup of the wpa_supplicant
> itself. Also, when people file me bugs, they often tell me that
> they ran "wpa_cli log_level debug" and thought it was persistent
> throughout reboot.

I think there would be much worse confusion if the debug level would
persist unexpectedly..

IMHO, this should be handled outside wpa_supplicant configuration file.
If there is a strong need to do this within wpa_supplicant, this would
need to be a configuration parameter that does not get written by
default without such behavior having been requested (e.g., through
having that configuration parameter present when loading the
configuration file). And even then, there would need to be a clearly
defined behavior for the case where multiple configuration files have
conflicting debug level parameter.

-- 
Jouni Malinen                                            PGP id EFC895FA