d80211 merge (was Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc)

[James Ketrenos <jketreno@linux.intel.com>]

Jeff Garzik wrote:
> James Ketrenos wrote:
>> If people have issues with with specific components of d80211 prior to
>> its merging, stand up and state what they are and how not fixing them
>> would negatively impact people that aren't using the d80211 subsystem.
>>
>> Don't take the above as me saying there aren't items that need to be
>> fixed/improved in d80211 -- there is work to be done.  But that
>> shouldn't stop it from being merged w/ the EXPERIMENTAL flag set.
> 
>> We reached the point where we should be in -mm a long time ago as soon
>> as both stacks could exist concurrently.  d80211 should have been in
>> Linus' tree a long time ago.
> 
> d80211 merge stoppers:
> - SMP issues (lack of locking, and overlocking via use of Big Network Lock)

So we can set BROKEN_ON_SMP on it and we're good.  The entire
description of EXPERIMENTAL in init/Kconfig matches perfectly what we
want -- bug reports, wider exposure, and a clear articulation that the
feature is unstable.

> - userspace ABI

What's the requirement on the userspace ABI?  That the existing wireless
extension interface needs to work, or ?

We can use the wireless extension currently to match (most of) the
existing WE functionality -- at least to get the majority of wireless
users up and running (for those that have cards that have d80211 drivers
anyway).

> It definitely shouldn't go upstream without that stuff.

How will merging with the existing locking problems or ABI issue
negatively impact people that aren't using the d80211 subsystem anyway?

If having the code there doesn't hurt anyone, why not get it out for
wider adoption, exposure, and contribution?

Why is there such a hesitation to merge this stack and help to
accelerate the set of functionality available with wireless on Linux?

James