hostap_driver_data vs. driver_ops. A bug?
Sat Mar 26 18:00:12 PST 2005
On Sat, Mar 26, 2005 at 03:53:58PM -0800, wayne liu wrote:
> hostap_driver_deinit() takes a parameter, void* priv, and casts it as
> hostap_driver_data. But the caller of this routine, hostapd_driver_deinit(),
> is passing in a param of type struct driver_ops when doing
The driver interface code (driver.c) uses struct hostap_driver_data as a
data structure that starts with struct driver_ops, but has private
variables in the end. Generic hostapd code does not know about these and
only has a pointer to struct driver_ops. Anyway, these are pointing to
the same address.
> As a related issue, in hostap_init(), the locally malloc'ed
> hostap_driver_data *drv does not seem to be held by anybody or free()'ed
> at the end and hence is lost when call is returned.
This pointer is stored in hapd->driver; this is due to drv and &drv->ops
pointing to the same address.
> So the question is should hapd->driver be pointing to hostap_driver_data
> instead of driver_ops ?
No, core hostapd code should not know anything about private driver
interface structures (e.g., struct hostap_driver_data).
> Given that the 1st variable of struct
> is driver_ops (by design?), access to any APIs in the driver_ops won't be
> messed up by the mismatch of the param. But what about other data fields?
Yes, this is by design; and no, this does not mess up other fields.
Jouni Malinen PGP id EFC895FA
More information about the Hostap