This finally introduces nl80211 and cfg80211 connect API,
and makes wireless extensions entirely self-contained in
cfg80211.
YES.
The last four patches still need more work:
* the combine patches require getting iwm ported
* the internalise patch requires getting orinoco
and rndis ported.
Samuel, who also worked a lot on the first three bits of
this series, is working on getting iwm ported, and then
we can stick this into the tree except for the last patch,
and gradually work on the rest. Maybe we even decide to
not internalise it this way because orinoco wants to keep
some ioctls that we'll not offer in cfg80211, not sure yet.
Also, this still needs a bit of work for auth algorithms.
Currently, the series breaks shared key auth. For iwm, the
device will only try the auth algorithm you ask it to use,
but mac80211 is able to select the algorithm automatically.
It might make most sense to make cfg80211 try different
algorithms if userspace didn't specify which one to use.
Anyway, comments welcome!
johannes
On Thu, 2009-06-25 at 21:37 +0100, Dave wrote:
> Regarding patch 11 (the internalise one), would it be better to:
> * continue to export cfg80211_wext_* for now
> * set mac80211s dev->wireless_handler to &cfg80211_wext_handler in
> iface.c (via a #define that's NULL if !CONFIG_WEXT)
> * specify a release when we expect all drivers, or at least those
> anyone cares about, to have converted?
>
> That removes the WE dependency from mac80211 but allows drivers to
> gradually implement cfg80211 support. I originally attempted doing it in
> one hit - that sucked, but may have been due to not having a clear idea
> of how cfg80211 is supposed to work.
Another idea I just had is that we could do everything like my
internalise patch, but have an if (!netdev->wireless_handlers) before
the assignment. That way, people could still have their own wireless
handlers. Additionally, subject to a Kconfig symbol, we could still
export the handlers, something like this:
config NEED_CFG80211_WEXT_HANDLERS
bool
#ifdef CONFIG_NEED_...
#define EXPORT_WEXT(sym) EXPORT_SYMBOL_GPL(sym)
#define __wext_static
static inline void cfg80211_assign_wext_handlers(netdev, handlers)
{
if (!dev->wireless_handlers)
dev->wireless_handlers = h;
}
#else
#warn "Having custom wireless handlers is deprecated!!"
#define EXPORT_WEXT(sym)
#define __wext_static static
static inline void cfg80211_assign_wext_handlers(netdev, handlers)
{
dev->wireless_handlers = h;
}
#endif
or something like that. Then drivers that are in transition could select
NEED_... and transition call by call even in the future after we switch
to the central model. Is it worth it? I don't know.
johannes
On Wed, Jun 24, 2009 at 5:07 AM, Johannes Berg<[email protected]> wrote:
> Maybe we even decide to
> not internalise it this way because orinoco wants to keep
> some ioctls that we'll not offer in cfg80211, not sure yet.
Hm, which ones?
Luis
Johannes Berg wrote:
> Yes. Mind you, I was not only talking about iwpriv, but also about
> things like orinoco's spy support or get/set sensitivity. The latter we
> don't quite understand -- can you tell us what it actually does? Spy
> support should just be removed, I think.
I've had a closer look at this.
The sensitivity basically controls the roaming threshold when handled by
firmware. It is a firmware setting, though the Agere driver also
validates the multicast rates based on it. The drivers/firmware use
terms like system scale, AP density, distance between APs.
There are 3 valid values:
3 - high density of APs. Maintain 11Mbps by roaming.
2 - medium density of APs. Maintain 2Mbps.
1 - low density. Maintain 1Mbps.
Although the values are defined in terms of the usable bitrate, the
(Intersil) documentation states that the implementation is based on SNR.
Dave.
On Thu, 2009-06-25 at 21:37 +0100, Dave wrote:
> Do we need to maintain these interfaces? I think allowing the same
> functionality via other means should be acceptable (since any software
> using these interfaces clearly doesn't work with any other hardware).
True.
> > Hm, which ones?
>
> orinoco has the following private wext handlers:
>
> reset firmware
> reset card
> get/set adhoc port
> get/set short preamble
> get/set ibss port
> get rid
>
> I've only ever had occasion to use the reset ioctls recently, when my
> card started seriously misbehaving (I suspect it's about to fail).
> debugfs or something?
Sounds appropriate.
> The get/set things could be done as module parameters. Preferred values
> will be model/fw specific - though I expect we have reasonable defaults
> picked during initialisation.
That too.
> Get RID reads settings off the card. Useful for debugging or reverse
> engineering, but I hope no-one uses it for anything else. Remove completely?
I suspect you can get rid of it, yes.
> Regarding patch 11 (the internalise one), would it be better to:
> * continue to export cfg80211_wext_* for now
> * set mac80211s dev->wireless_handler to &cfg80211_wext_handler in
> iface.c (via a #define that's NULL if !CONFIG_WEXT)
> * specify a release when we expect all drivers, or at least those
> anyone cares about, to have converted?
Sure. I don't think we need to specify a release since there's only
three drivers so far -- orinoco, rndis and iwm. The latter is taken care
of, and the two others shouldn't be much of a problem either.
> That removes the WE dependency from mac80211 but allows drivers to
> gradually implement cfg80211 support. I originally attempted doing it in
> one hit - that sucked, but may have been due to not having a clear idea
> of how cfg80211 is supposed to work.
Yeah, I agree, doing it in one go will probably overwork anyone who
attempts it, otoh once we actually convert everything in the tree all
the remaining drivers will have to be done in one go. So I think we
should just wait until all drivers are converted and then simply swap. I
can help with rndis/orinoco too.
> It also means orinoco can keep its wext private functions for a bit longer.
Yes. Mind you, I was not only talking about iwpriv, but also about
things like orinoco's spy support or get/set sensitivity. The latter we
don't quite understand -- can you tell us what it actually does? Spy
support should just be removed, I think.
Additionally, at the wireless summit today (yesterday by the time you
read this) we decided to allow cfg80211 drivers to continue exporting
iwpriv handlers, so that existing factory calibration interfaces or
similar can be maintained going forward even with future drivers.
However, this is understood to be purely for backward compatibility with
existing calibration or similar tools.
johannes
Luis R. Rodriguez wrote:
> On Wed, Jun 24, 2009 at 5:07 AM, Johannes Berg<[email protected]> wrote:
>
>> Maybe we even decide to
>> not internalise it this way because orinoco wants to keep
>> some ioctls that we'll not offer in cfg80211, not sure yet.
Do we need to maintain these interfaces? I think allowing the same
functionality via other means should be acceptable (since any software
using these interfaces clearly doesn't work with any other hardware).
> Hm, which ones?
orinoco has the following private wext handlers:
reset firmware
reset card
get/set adhoc port
get/set short preamble
get/set ibss port
get rid
I've only ever had occasion to use the reset ioctls recently, when my
card started seriously misbehaving (I suspect it's about to fail).
debugfs or something?
The get/set things could be done as module parameters. Preferred values
will be model/fw specific - though I expect we have reasonable defaults
picked during initialisation.
Get RID reads settings off the card. Useful for debugging or reverse
engineering, but I hope no-one uses it for anything else. Remove completely?
Regarding patch 11 (the internalise one), would it be better to:
* continue to export cfg80211_wext_* for now
* set mac80211s dev->wireless_handler to &cfg80211_wext_handler in
iface.c (via a #define that's NULL if !CONFIG_WEXT)
* specify a release when we expect all drivers, or at least those
anyone cares about, to have converted?
That removes the WE dependency from mac80211 but allows drivers to
gradually implement cfg80211 support. I originally attempted doing it in
one hit - that sucked, but may have been due to not having a clear idea
of how cfg80211 is supposed to work.
It also means orinoco can keep its wext private functions for a bit longer.
Thanks,
Dave.
On Sun, 2009-06-28 at 10:26 +0100, Dave wrote:
> Johannes Berg wrote:
> > Yes. Mind you, I was not only talking about iwpriv, but also about
> > things like orinoco's spy support or get/set sensitivity. The latter we
> > don't quite understand -- can you tell us what it actually does? Spy
> > support should just be removed, I think.
>
> I've had a closer look at this.
Thanks!
> The sensitivity basically controls the roaming threshold when handled by
> firmware. It is a firmware setting, though the Agere driver also
> validates the multicast rates based on it. The drivers/firmware use
> terms like system scale, AP density, distance between APs.
>
> There are 3 valid values:
>
> 3 - high density of APs. Maintain 11Mbps by roaming.
> 2 - medium density of APs. Maintain 2Mbps.
> 1 - low density. Maintain 1Mbps.
>
> Although the values are defined in terms of the usable bitrate, the
> (Intersil) documentation states that the implementation is based on SNR.
That's actually what people suspected when I asked around at the summit,
and it seemed the general consensus is that we need a proper setting for
that in nl80211 along with some of the roaming capability exports.
So until that happens, the last patch won't get in anyway, and we'll see
about the NEED_... stuff later.
johannes
Johannes Berg wrote:
> On Thu, 2009-06-25 at 21:37 +0100, Dave wrote:
>
>> That removes the WE dependency from mac80211 but allows drivers to
>> gradually implement cfg80211 support. I originally attempted doing it in
>> one hit - that sucked, but may have been due to not having a clear idea
>> of how cfg80211 is supposed to work.
>
> Another idea I just had is that we could do everything like my
> internalise patch, but have an if (!netdev->wireless_handlers) before
> the assignment. That way, people could still have their own wireless
> handlers.
I had that same thought...
> Additionally, subject to a Kconfig symbol, we could still
> export the handlers, something like this:
<snip>
> or something like that. Then drivers that are in transition could select
> NEED_... and transition call by call even in the future after we switch
> to the central model. Is it worth it? I don't know.
Neat. I tend to prefer avoiding these indirections and keeping things
clean. I'd vote (if I had one) to take the NEED_ behaviour now, and
transition at some point.
Thanks,
Dave.