Hi all !
Today I got a connection of libertas + cfg80211 to an AP in the
modes WEP40, WEP104, WPA, WPA2 and also with no encryption at
all.
I still have some loose odds and ends, but the initial work is
done and we can consider if we want this feature included in the
linux kernel --- or not.
However, an cfg80211-converted libertas has some missing
features, that others migth think are important: no
libertas-mesh, no monitor mode, no ad-hoc mode. Nothing of this
is per-se impossible with cfg80211, it just needs to be
implemented.
I see several possibilities:
1. Let it mature outside
---------------------
Keep libertas+cfg80211 out-of-tree until it supports some minimal
functionality.
Pro: no one misses a feature
Cons: no widespread testing of the cfg80211 features
2. Take it as it is
----------------
Nah, not exactly at it is today, but let us stop by missing
monitor-mode, adhoc etc --- for now. Implement that later, once
libertas is in-kernel and people need it.
Pro: widespread testing of the cfg80211 features
Cons: people miss some functions when they upgrade the kernel
3. Make things configurable
------------------------
I could create a Kconfig "choice" entry, where one can select
CONFIG_LIBERTAS_WEXT or CONFIG_LIBERTAS_CFG80211. I would then
provide a bunch of cleanup patches, e.g. to move all things in
struct "libertas_private" into one place that are WEXT-related.
Pro: no one misses his beloved feature (because it's in
CONFIG_LIBERTAS_WEXT)
Pro: some people can test the cfg80211-features (with
CONFIG_LIBERTAS_CFG80211)
Cons: we have a higher amount of #ifdef in Libertas code until
either libertas-cfg80211 got all the features added OR until
WEXT get's removed from the kernel.
--
http://www.holgerschurig.de
> If you can keep working on this, I'd say lets shoot for kernel
> inclusion in 2.6.34.
I'm not sure if I can keep working on this: this week we move our
office and I can at any time assigned to a new project. That
said: I plan to keep working on this.
Okay, my current plan is to isolate WEXT stuff, e.g. delete what
is already unused, move WEXT related stuff from dev.h into
assoc.h/wext.h/scan.h (whereever it fits best), move WEXT
related stuff in the lbs_private definition next to each other.
Most of this won't do any functional change, but would make the
cfg80211 patch smaller in size.
> But we'd need at least adhoc support before then.
Seems that I need to experiment with AD-HOC after all. Never used
it before :-)
--
http://www.holgerschurig.de
> BTW, do you have any rough counts of the LoC you've removed from the
> driver as a result of this? Ideally you could remove a cargo-ship's
> worth of work I did back in 2007 and you know what? I like that :)
Oh, that's easy. The last diffstat for my cfg80211 patch was
22 files changed, 2107 insertions(+), 1855 deletions(-)
But the patch doesn't currently remove some files, so if I do
$ wc --lines wext.* 11d.* scan.* assoc.*
2320 wext.c
10 wext.h
696 11d.c
105 11d.h
1212 scan.c
33 scan.h
1865 assoc.c
16 assoc.h
6257 tota
So, we have 1855 + 6257 = 8112 deletions.
On Fri, 2009-10-16 at 14:26 +0200, Holger Schurig wrote:
> Hi all !
>
> Today I got a connection of libertas + cfg80211 to an AP in the
> modes WEP40, WEP104, WPA, WPA2 and also with no encryption at
> all.
>
> I still have some loose odds and ends, but the initial work is
> done and we can consider if we want this feature included in the
> linux kernel --- or not.
>
>
> However, an cfg80211-converted libertas has some missing
> features, that others migth think are important: no
> libertas-mesh, no monitor mode, no ad-hoc mode. Nothing of this
> is per-se impossible with cfg80211, it just needs to be
> implemented.
>
> I see several possibilities:
>
>
> 1. Let it mature outside
> ---------------------
> Keep libertas+cfg80211 out-of-tree until it supports some minimal
> functionality.
>
> Pro: no one misses a feature
> Cons: no widespread testing of the cfg80211 features
>
>
> 2. Take it as it is
> ----------------
> Nah, not exactly at it is today, but let us stop by missing
> monitor-mode, adhoc etc --- for now. Implement that later, once
> libertas is in-kernel and people need it.
If you can keep working on this, I'd say lets shoot for kernel inclusion
in 2.6.34. But we'd need at least adhoc support before then. The mesh
stuff will be interesting, yes, but hopefully we can hammer out what the
specific interface there should be.
I'm somewhat hesitant about pushing a big change like this to 2.6.33
without a lot more testing by people that have the hardware. I haven't
had time to poke at this yet besides looking at the patches.
BTW, do you have any rough counts of the LoC you've removed from the
driver as a result of this? Ideally you could remove a cargo-ship's
worth of work I did back in 2007 and you know what? I like that :)
Dan
> Pro: widespread testing of the cfg80211 features
> Cons: people miss some functions when they upgrade the kernel
>
>
> 3. Make things configurable
> ------------------------
> I could create a Kconfig "choice" entry, where one can select
> CONFIG_LIBERTAS_WEXT or CONFIG_LIBERTAS_CFG80211. I would then
> provide a bunch of cleanup patches, e.g. to move all things in
> struct "libertas_private" into one place that are WEXT-related.
>
> Pro: no one misses his beloved feature (because it's in
> CONFIG_LIBERTAS_WEXT)
> Pro: some people can test the cfg80211-features (with
> CONFIG_LIBERTAS_CFG80211)
> Cons: we have a higher amount of #ifdef in Libertas code until
> either libertas-cfg80211 got all the features added OR until
> WEXT get's removed from the kernel.
>
>