On Mon, Aug 12, 2024 at 3:39 PM Hui Bai <hui.bai@xxxxxxx> wrote:
>
> Hi Jouni Malinen,
>
> Currently on Zephyr, we are using Monolithic build, which means both wpa_supplicant and hostapd files will be built into one single binary.
> I didn't quite get your idea of using function pointers to the driver interface. But based on my understanding, even I take your suggestions, the redefinition build error will still occurred with Monolithic build.
>
> Regards,
> Hui Bai
>
> -----Original Message-----
> From: Jouni Malinen <j@xxxxx>
> Sent: Saturday, August 10, 2024 3:49 PM
> To: Hui Bai <hui.bai@xxxxxxx>
> Cc: hostap@xxxxxxxxxxxxxxxxxxx
> Subject: [EXT] Re: [PATCH] hostapd: Rename event handling functions in hostapd for
>
> Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button
>
>
> On Thu, Jun 13, 2024 at 06:32:01AM +0000, Hui Bai wrote:
> > On Zephyr, both wpa_supplicant and hostapd are supported. One compilation error was found due to function name conflict.
> > Both wpa_supplicant and hostapd has its own global event and event handlers with same name:
> > wpa_supplicant_event
> > wpa_supplicant_event_global
> >
> > To fix the compilation error, rename above functions in hostapd for Zephyr as below:
> > hostapd_event
> > hostapd_event_global
>
> This does not look like something that would really work at all in hostap.git, i.e., this is based on something that has other changes and as such, I'm not sure why this particular change should be in hostap.git.
>
> Those functions have the same name for a reason, i.e., those are the functions that are called from the driver interface code for either hostapd or wpa_supplicant. If there is need to make this work with both hostapd and wpa_supplicant somehow linked into a single binary, the driver wrappers would need changes. For that, the cleaner way of updating the design would be by registering wpa_supplicant_event and wpa_supplicant_event_global as function pointers to the driver interface and using those function pointers instead of direct calls. That is something that I could consider applying to hostap.git.
> somehow linked into a single binary,
This and a couple of other patches related to single binary using both
hostap and wpa_supplicant are
in the context of an embedded OS (ZephyrRTOS) where there are only
threads and no processes.
So, hostapd and WPA supplicant run in separate threads and belong to
the same binary and we see
conflicts in that case.
> For that, the cleaner way of updating the design would be by registering wpa_supplicant_event and
> wpa_supplicant_event_global as function pointers to the driver interface and using those function
> pointers instead of direct calls. That is something that I could consider applying to hostap.git.
I guess what Jouni is proposing is something like below, where we can register
both a global and per-interface event callback and both AP and STA
interfaces can
register their own callback using per-interface callbacks.
diff --git a/src/drivers/driver.h b/src/drivers/driver.h
index f39ea6560..64a6c169c 100644
--- a/src/drivers/driver.h
+++ b/src/drivers/driver.h
@@ -2550,6 +2550,9 @@ enum nested_attr {
NESTED_ATTR_UNSPECIFIED = 2,
};
+
+typedef void (*wpa_event_callback)(void *ctx, enum wpa_event_type event,
+ union wpa_event_data *data);
/**
* struct wpa_driver_ops - Driver interface API definition
*
@@ -2937,7 +2940,7 @@ struct wpa_driver_ops {
* use init2() function instead of init() to get the pointer to global
* data available to per-interface initializer.
*/
- void * (*global_init)(void *ctx);
+ void * (*global_init)(void *ctx, wpa_event_callback cb);
/**
* global_deinit - Global driver deinitialization
@@ -2959,7 +2962,8 @@ struct wpa_driver_ops {
* This function can be used instead of init() if the driver wrapper
* uses global data.
*/
- void * (*init2)(void *ctx, const char *ifname, void *global_priv);
+ void * (*init2)(void *ctx, const char *ifname, void *global_priv,
+ wpa_event_callback cb);
/**
* get_interfaces - Get information about available interfaces
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
