On Thu, Nov 18, 2010 at 3:11 AM, Theodore Tso <tytso@xxxxxxx> wrote: > Luis, > > I'm having a little trouble understanding what it is your proposing. I'm both, explaining why some companies tend to have a hard time working directly upstream and using 802.11 as an example, and trying to find ways to help change old habits to help companies work upstream, even if that means for non 802.11 drivers, but by using 802.11 landscape as an example case study. My goal is to show a clear path for vendors to work with proper Linux upstream first for bring up, that is the long term goal I am trying to envision but at the same time trying to address the other goals companies have to keep supporting the other OSes and help the ecosystem by coming up with ways to help guide companies or share more code for the other OSes, not just for 802.11 but for other subsystems. > I *think* you are suggesting that > > a) ÂSome portion of the "OS agnostic crap" be relicensed under a BSD or Apache-style license. Well this is certainly possible, question is if we can gain from sharing a common OS agnostic API, stuff it into staging and encourage other vendors to consider using it for staging drivers. For a proper port we could use spatch patches to then remove the OS agnostic crap and start skinning the driver. Today in staging we'd do this step by step by porting over each typedef or struct the vendor used, or we just re-write the driver. > And I think what you are suggesting would fall in that camp is the parts of the Linux 802.11 stack? > > b) ÂThat the "OS agnostic crap" be moved into staging. > > Can we ignore where the code lives for now? Â I think (b) doesn't make any sense at all. But its OK for each staging driver to have their own OS shim stuff. drivers/staging/ath6kl/os/linux/ Seems a bit at odds to be OK with this but not with a common OS shim in staging for different drivers. > And as far as (b) is concerned, I think what you are suggesting isn't so much about the code, > but trying to somehow encourage, via the carrot of making it easy to push vendors into > agreeing that the Linux 802.11 wireless API should be considered the OS independent > interface layer that random vendors creating 802.11 drivers can interface against. After Broadcom started hacking upstream and seeing TI start to work upstream I actually believe for 802.11 we're pretty much set on getting most if not all vendors on board with upstream today :) but I was using 802.11 as an example of the challenges faced by companies and old habits held, and hoping to find rational suggestions to encourage either doing upstream first or helping die out the old habits with better replacements which can suit us and the community / vendors. Sure - for 802.11 a shim wrapper against mac80211 would be ideal for sure, but we'd then still need a common permissive licensed 802.11 stack for vendors to use, and an OS shim. > And to make that easy, you want to relicense the 802.11 stack under a BSD/Apache license so > that it makes life easy for people who are creating drivers for Windows XP. Â Do I have that right? I don't want to change the license of our 802.11 stack but am stating that if a good 802.11 stack existed which was permissive licensed that vendors would pick it. Its why a lot of vendors ended up picking net80211 to base their own 802.11 stacks out of. Sure, if mac80211 was permissive licensed we can likely get more traction with development by considering using it as the common 802.11 stack for other OSes that do not have their own 802.11 stack as well but that doesn't necessarily have to be the answer. Since a common 802.11 stack is used and will be used by vendors for years to come I wondered if it made sense to stuff one for vendors into staging so that they can use for this purpose. Earlier (not now with ath6kl and brcm80211) 802.11 staging drivers all implemented their own 802.11 stack, so why not encourage using something more common and shared between vendors. This is surely not our job as upstream Linux developers, but just pointing out that these stacks will exist and be maintained for years to come. I wonder what other type of similar situations there are with other subsystems. > Assuming I understand the motivations of your proposal and what it is you were proposing > in the first place, might another course of action which might prove as efficient, if not more > so in the long term, is for some volunteer (perhaps at Atheros) to create some freely licensed > new code that creates a glue layer between the Linux interfaces that wireless drivers use to > plug into Linux's 802.11 layer, and to the 802.11 layer for Windows 7 and Mac OS X. Right, this is along with my thinking but I'll note that our ath9k driver is completely independent and the only code shared today would be the hardware code, stuff that goes into the ath9k_hw module. But sure, other things like OS wrappers to help drivers work with different OSes could potentially be released, if not seen as competitive advantage. Getting a wrapper to be created for the different OS 802.11 stacks would certainly help as well but that would be a bit of a challenge as we'd need to hope for at least some similarity between 802.11 stacks. > ÂFurthermore, to make this glue layer GPL with the exception clauses that allows the glue code to link into Windows 7 and Mac OS X. For that matter just make it ISC / permissive licensed as this is GPL Compatible. > What this provides for is a wonderful leverage for hardware vendors. Â If they provide GPL'ed > code for their core hardware drivers that link against the Linux 802.11 layer, at one fell swoop > they also get Windows 7 and Mac OS X drivers for free! Yes, indeed ! That would be ideal indeed, but we'd need then an 802.11 stack which is also permissive licensed and then make APIs for that 802.11 stack to match mac80211's or cfg80211's or bridges between then. Because ultimately you will still need some 802.11 stack for some OSes that don't have one. > Better yet, it doesn't require getting permission from the Linux world, since what is necessary is the existence > of new glue code that allows the hardware dependent code that previously was Linux specific, and which now' > allows it to plug into the glue code which then allows it to become hardware independent code for > Windows 7 and Mac OS X. Sure, that can likely work if the APIs don't change as often or we can find some common ground. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
