libertas + cfg80211: road for kernel inclusion?

libertas + cfg80211: road for kernel inclusion?

[Holger Schurig]

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

Re: libertas + cfg80211: road for kernel inclusion?

[Dan Williams]

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

Re: libertas + cfg80211: road for kernel inclusion?

[Holger Schurig]

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

Re: libertas + cfg80211: road for kernel inclusion?

[Holger Schurig]

> 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