2011/9/20 John W. Linville <linville@xxxxxxxxxxxxx>: > On Tue, Sep 20, 2011 at 03:21:14PM +0200, Johannes Berg wrote: > >> Now, don't get me wrong -- I don't think the duplication is a good >> thing. A lot of the PHY code could be shared. However, I think it will >> probably not be possible for much longer to share the higher level MAC >> code that programs the SHM etc. > > It would be nice to see some of this. I don't think anything is > stopping either Broadcom _or_ the b43 team from posting such patches. > >> So I don't claim to know what the solution is, but I think simply >> rejecting the Broadcom effort like most people seem to imply is a good >> solution at all. It will leave all of us in a bad spot by creating a >> driver that has to support too many different devices. > > I'm inclined to agree. Despite recent heroic efforts, b43 remains > behind in it's support for current features of Broadcom hardware. > As developers find other gainful interests, that gap is sure to widen > -- it certainly was quite wide just a few months ago. And brcmsmac stays behind b43 if you count feature different than performance. Monitor, RFKILL, Ad-hoc, AP, hw crypt, supported PHYs, etc. And what if Broadcom decides to abound their brcm80211 project? I vote for working together, I can not see a better solution. > As Johannes implies, it seems likely that newer Broadcom hardware will > need to be supported by a different/new driver anyway. Is there > some reason why that new driver needs to have a b43 pedigree? > If we want/expect Broadcom to support that new driver, is it so > unreasonable to allow them to start from the codebase they prefer? > I don't think it is. We still don't have any clue, when is that going to happen. > Broadcom has come a long way in the wireless arena. I think we would > be better served by bringing them into the fold than by continuing > to demand what they don't feel able to provide. That's why I asked so many times already to discuss future with them. -- Rafał _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
