[PATCH 2/2] wpa_supplicant: Allow re-open of log files with SIGHUP

Ben Greear greearb
Thu Nov 18 11:42:36 PST 2010


On 11/18/2010 11:35 AM, Jouni Malinen wrote:
> On Thu, Nov 18, 2010 at 09:48:34AM -0800, Ben Greear wrote:
>> I can change it to SIGUSR2 or something like that easily enough.
>
> I think I would actually preference not to use a signal for this to make
> it work systems that do not provide similar signal mechanism or at least
> not something like SIGUSR2.. The core wpa_supplicant needs to be
> portable and I don't think I would add a new wrapper for this type of
> use.
>
>> No big reason...except that is where I made params a static global.
>> Is there a more proper way to get access to the wpa_debug_file_path?
>
> Either save a copy of the path in src/utils/wpa_debug.c and provide a
> new function to re-open the log file instead of using or make a copy of
> it into struct wpa_global in wpa_supplicant_init().

Ok, saving a copy in wpa_debug.c seems a good option.

>
>> Since SIGHUP seems a bad idea, should I just leave the eloop_register_signal call in
>> place but use a different signal?
>
> Would you be fine with a new control interface command instead of
> signal? That would work with all targets and would not need any
> portability wrappers to be added. If that is not fine, I would just add
> this into the current reconfig handler and try to live with
> reconfiguration happening at the same time.

Like a new wpa_cli command?  That is fine with me..I just want some
way to roll the logs.  I definitely don't want to bounce all interfaces
each time I roll a log, so using existing reconfig handler isn't a good
option for me.

Any hints on where to start with a new wpa_cli command?

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com




More information about the Hostap mailing list