wireless: recap of current issues (stack)

Stack
=====

Is the in-kernel stack up-to-date w/ SourceForge?  No.  Why not?
Can this development be brought into wireless development kernels?

Can the in-kernel stack be saved?  With the addition of softmac?
Is it possible to extend softmac to support virtual wlan devices?
If not, how do we proceed?

How do we get more drivers in-kernel?  (Multiple stacks probably
don't help beyond the short-term timeframe.)

I think we need to rally as many driver writers as possible a) to
get into the kernel now; and, b) move away from duplicating stack
features.  I don't see how to achieve that with the DeviceScape stack
in the short- or medium-term timeframe.  I get the impression that
porting drivers from one stack to the other is not all that painful,
particularly in the ieee80211->DeviceScape direction.  Is it reasonable
to expect short-term development to stay with the ieee80211 stack,
while planning either a migration to DeviceScape or a major ieee80211
overhaul based on the DeviceScape code?

Do we need to have both wireless-stable and wireless-devel kernels?
What about the suggestion of having both stacks in the kernel at once?
I'm not very excited about two in-kernel stacks.  Still, consolidating
wireless drivers down to two stacks is probably better than what we
have now...?  Either way, we would have to have general understanding
that at some point (not too far away), one of the stacks would have
to disappear.
-- 
John W. Linville
linville@tuxdriver.com

On Fri, 2006-01-13 at 17:22 -0500, John W. Linville wrote:

Can the in-kernel stack be saved?  With the addition of softmac?
Is it possible to extend softmac to support virtual wlan devices?
If not, how do we proceed?

Well, softmac doesn't really have too many issues [that make it
incompatible with the planned stuff, that is]. Right now it layers
above ieee80211_device, and it would continue doing so, with
ieee80211_device transformed into the representation of the virtual STA
device.

johannes