Re: [RFC] Alternate WE-21 support (core API)

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2006-09-12 at 09:17 -0700, Jean Tourrilhes wrote:

> 	I was initially very negative towards the WPA API (WPA +
> extended scan), because it's so complex. I went back and forth with
> Jouni trying to simplify it, but we did not manage to gain much. I
> trust that Jouni did the best he could, that's just the nature of the
> beast.

:)

> 	I was thinking of the WE -> nl80211 compatibility. It's pretty
> trivial to do as far as WE is concerned, you just need to hack
> get_handler() to return the nl80211 handler. Or, if you don't like a
> single handler, you could have one wrapper per ioctl, which is even
> easier.

Currently, I don't rely on that at all, nl80211 relies on the
driver/stack assigning ieee80211_ptr in the netdevice field and uses
that as a cookie. IOW, get_handler() gets to die.

My current plan for compatibility was to make all drivers cfg80211-away
by making them register themselves with cfg80211 with a callback struct
with entries for each thing they need to handle, and then introduce a
translation layer that translates incoming WE requests into the
appropriate callbacks just like nl80211 translates the incoming
genetlink messages.

> 	Do you have a recent version of your code so that I can see
> how it can hook on your side ? I think we could put the generic
> mechanism in place early so that people can add specifics as they need
> them.

The latest patches were posted to netdev quite a while ago, I haven't
done anything with them recently.

One thing I'd like to do is rename the include from net/nl80211.h to
net/cfg80211.h so that it's more obvious that it isn't purely netlink
(include/nl80211.h is the userspace netlink interface so that stays).

johannes