| |||||||||||||
On multi-platform driversOn multi-platform driversPosted Sep 9, 2011 20:12 UTC (Fri) by utoddl (subscriber, #1232)Parent article: On multi-platform drivers This is an overreaction and misinterpretation. Why should "architectural alignment" necessarily mean iron-fisted control of the code? Rather, it offers a hope that by the time new hardware makes its way to retail shelves people running modern kernels will find that it Just Works out of the box. It also could mean that issues found and fixed by those krazy Linux kids may improve the vendor's overall product line, thus rewarding financially a company who's willing to make the effort to play by our rules. "Architectural alignment" does not suggest to me that Broadcom would be less than accepting of changes that make make their Linux driver or support better. They've obviously been graciously taking suggestions from established kernel devs for the last year in the way we would hope. I see no reason to expect less from them in the future. They've spent the effort to learn how to work "with" vs. "in spite of" the Linux Way. Good on 'em. Turn the argument around: Why would a vendor and hardware manufacturer be in any worse position to maintain -- in coordination with a highly competent kernel development community -- drivers for current and future hardware that they understand fully than a handful of developers working in their spare time with incomplete specs and spurious bug reports? This looks to me like a company trying hard to provide exactly the kind of support that others have been criticized for not providing for years. Kudos to Broadcom. This may be the ideal model for companies to work with the community; time will tell. I'm willing to give it a chance before declaring it an untenable approach.
(Log in to post comments)
On multi-platform drivers Posted Sep 10, 2011 20:46 UTC (Sat) by alecs1 (guest, #46699) [Link]
These are mostly my thoughts too, but the article is useful in explaining the logic behind kernel development way of thinking, not necessarily an overreaction.
If the Broadcom driver gets into the kernel now based on merit, it doesn't necessarily mean the vendor will be able to do whatever it wants in the future. Broadcom is not the Linux kernel gatekeeper. If things don't clean up between the main actors in this, I trust Linus will make the correct compromise.
On multi-platform drivers Posted Sep 12, 2011 21:03 UTC (Mon) by michaeljt (subscriber, #39183) [Link]
> If the Broadcom driver gets into the kernel now based on merit, it doesn't necessarily mean the vendor will be able to do whatever it wants in the future. Broadcom is not the Linux kernel gatekeeper. If things don't clean up between the main actors in this, I trust Linus will make the correct compromise.
Right. It seems to me that the main problem raised in the article (that kernel people will want to be able to make changes without consulting Broadcom first) is something Broadcom will have to deal with, not something that should be much of a problem for other kernel developers. Broadcom have made their code GPL, and there is always the - pretty easy - option of forking maintenance of it if they don't play the way other kernel developers would like, so it seems reasonable to give them a chance. If their multi-platform driver maintenance works out it the experience could benefit everyone.
On multi-platform drivers Posted Sep 12, 2011 20:28 UTC (Mon) by kleptog (subscriber, #1183) [Link]
I agree there's a lot of noise going around. The phrase "architectural alignment" seems to have been interpreted to mean the worst possible things, but the driver was being proposed for merging to mainline so evidently people thought it would be acceptable code-wise. I certainly haven't seen anyone post a single line of code showing anything the kernel devs won't stand for.
On multi-platform drivers Posted Sep 18, 2011 2:00 UTC (Sun) by kabloom (guest, #59417) [Link]
I haven't looked at any of the code, and I understand people's concern about what might happen in future refactorings of the kernel wireless system, but the kernel's code review process is pretty demanding in terms of how much work (and modification) a module developer has to do to conform to the kernel's way of doing things before they get accepted into the mainline.
If Broadcom has managed to satisfy the kernel developers' demands for conformance, and they still feel that there's sufficient architectural alignment between the Linux driver and their other drivers, then Broadcom's definition of "sufficient architectural alignment" is probably loose enough that they'll be able to maintain sufficient architectural alignment in the face of future kernel development work.
|
|||||||||||||