hostap_driver_data vs. driver_ops. A bug?

[Jouni Malinen]

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 
>     hapd->driver->deinit(hapd->driver);

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
> hostap_driver_data
> 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