James Ketrenos wrote:
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.
heh, no, we don't merge stuff that's obviously incomplete or broken.
BROKEN_ON_SMP is one step before driver death, not the first baby step
of a driver.
- userspace ABI
What's the requirement on the userspace ABI? That the existing wireless
extension interface needs to work, or ?
The requirement is that code should not go upstream if its userspace
interface is highly likely to change. ABI mistakes are locked in stone
once they hit the upstream kernel, for the most part.
As long as the userspace ABI is "baked" and generally agreed upon, then
the requirement is satisfied.
Speaking specifically, Linus noted recently d80211 should maintain
backwards compatibility with the WE userspace ABI, so that existing
wireless tools keep working, and I definitely agree. For additional
functionality/flexibility, I presume there will be some sort of netlink
extensible interface (cfg80211 I think?) that newer wireless tools will
use. In time, the WE back-compat ABI could become an optional module
that users can disable.
How will merging with the existing locking problems or ABI issue
negatively impact people that aren't using the d80211 subsystem anyway?
Irrelevant.
We don't merge code with obvious bugs, especially when the justification
is "merging means the bugs will be fixed."
If a codebase isn't getting bugs fixed as it is, that is a strong reason
AGAINST merging it.
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?
A codebase has to have developers who will put in the minimum effort to
make sure it is completely SMP safe, and that the ABI issues are handled
in the way they are handled throughout the rest of the kernel.
"Wider participation" is not a blank check to merge every half-baked
codebase out there. One of the things that's nice about git is that
things enter the kernel MORE baked than in the past, because distributed
development means stuff occurs in parallel.
"Getting is upstream" is the eventual goal, NOT a magic panacea that
wipes away existing ills.
Jeff, who, just like you, wants to see d80211 merged
-
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
