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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
