Non-remote control of wpa_supplicant

[Ted Merrill]

Jouni,

Sorry, i lost your reply until now.
I've switched over to non-digest which will help a lot.

Regarding the style i used for callbacks:
Passing the pointer  to the object to the callback provides, in my opinion, 
important type safety... and information from the object including cookies 
are readily available via access functions (inline is possible) but incur no 
overhead if not needed.

The code will be part of the next code i send you.

netx/prev are indeed part of the internal implementation and there would be no 
access functions for them.
cookie could be passed as part of the create function, which would be 
reasonable since a cookie is desireable in most cases.

-Ted

>> The wpa_ctrl feature allows control of wpa_supplicant from another
>> process/program.  For control within the same process/program, calls can be
>> made "directly" to the needed subroutines.
>> But one thing that is missing is that there is general way to monitor state
>> changes from within the same process except perhaps by periodic polling.
>> I've added the following to my local copy (in wpa_supplicant_i.h):
>
>This looks like a good addition.
>
>> /**
>>  * struct wpa_supplicant_cb - State change callback
>>  *
>>  * Callback function is called AFTER the state is marked as changed.
>>  * Information from the callback struct should be obtained via
>>  * the access functions (below).
>>  */
>> struct wpa_supplicant_cb {
>>         struct wpa_supplicant_cb *next;
>>         struct wpa_supplicant_cb *prev;
>>         void (*cb_func)(struct wpa_supplicant_cb *cb);
>>         struct wpa_supplicant *wpa_s;
>>         void *cookie;   /* passed to cb */
>> };
>
>I normally use callback functions that take a void* context argument
>which, I would assume, this cookie value is for. Is there any particular
>reason for passing struct wpa_supplicant_cb to the callback? The
>next/prev pointers look internal to the list implementation and it might
>be clearner to just pass in wpa_s and cookie as the cb_func arguments
>(cookie could be registered with _cb_create, so no need for a separate
>_cb_cookie_set functions).