hostap_driver_data vs. driver_ops. A bug?

[wayne liu]

I'm a newbie to the list and have been reading the src of ver 0.3.7.
I have a question here, probably directed to Jouni.

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);

Similarly, hostap_wireless_event_init() takes a param and 
casts it into hostap_driver_data*, but the caller,
hostapd_wireless_event_init(),
is passing in hapd->driver.

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.

So the question is should hapd->driver be pointing to hostap_driver_data 
instead of driver_ops ?  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?
Actually in hostap_wireless_event_init(), the statement: 
	drv->wext_sock = -1;
would have screwed things up.  The fact the it didn't (did it?) probably means 
I'm missing something ?