Broadcom's wireless drivers, one year later

Posted Aug 31, 2011 18:36 UTC (Wed) by johannbg (guest, #65743)
In reply to: Broadcom's wireless drivers, one year later by dlang
Parent article: Broadcom's wireless drivers, one year later

>and who is going to do this work?

I would assume both parties that are trying to reach the same goal if not I would think the vendor him self would have the final saying in it after all he knows his product best and what's coming up next and has all the required information about his product and so fourth and so on hence having the vendor backing the driver development beats the reverse engineering any time. ( ofcourse the best end result is if they could work together ).

So I quote Henry's response to the thread

"As we add new, much more complicated chips, those chips will also get complete, full-performance, fully-tested support."

If you put this into end user perspective this is not even an question of which one should be dropped if it comes down to it.
( which could be limited to "once you provide equal or better support than b43 we will replace your driver with b43 in mainline" )

Fully supported Broadcom chipsets backed tested and production ready which is on various range of hw available at the same or similar time as it is for other OS vs reversed engineered Broadcom chipset limited to what ever hw range the engineers have access to and what time they have to spare working on reverse engineering it *from* the time they acquired that hw.

On in on I think the ramification of turning down vendors when they finally decide/have been talked into investing their resources into open sourcing their drivers and get it into mainline is rather great.

For all we know they might decide that this was a lost cause, flag the effort as tried and tested with expenses down the drain and never look back.

Broadcom's wireless drivers, one year later

Posted Aug 31, 2011 21:33 UTC (Wed) by raven667 (subscriber, #5198) [Link] (2 responses)

The thing that the kernel developers are optimizing for is the ability to do long-term maintenance on their own. They presume that the person who wrote the code might not be the only person who needs to maintain the code which is why they are so insistent that any code follows the style guidelines and does not have it's own internal abstraction layers or API that other kernel developers would be unfamiliar with. They are absolutely willing to pass on a working driver if it is seen to increase the long-term maintenance burden of the kernel. Given that others will end up maintaining this driver in the future, don't they have a choice in what they accept?

I think this attitude is largely driven by the reiserfs debacle, which may have been mentioned elsewhere, where a large body of code was accepted in good faith that it would be maintained but was quickly abandoned which left no-one available who understood it and was qualified to maintain it. It put the kernel developers in an awful position, distributing code that they were unable to effectively support, that they are desperate to never repeat.

Broadcom's wireless drivers, one year later

Posted Sep 1, 2011 10:02 UTC (Thu) by johannbg (guest, #65743) [Link] (1 responses)

How easy is it for vendors to access documentation on how they should interact with kernel so their side of things work as are expected?

and at the same time...

How easy is it for hackers to access vendor documentation so they can properly work on long time supporting their product?

Hence is that not something that needs to be solved with documentation requirement before acceptance?

I'm not seeing how it can be expected that somebody can provide long time support for something if he does not have the documentation on how things are supposed/expected to work.

I think both vendor and the kernel community might needs some work on providing/improving their documentation.

Broadcom's wireless drivers, one year later

Posted Sep 1, 2011 17:58 UTC (Thu) by raven667 (subscriber, #5198) [Link]

There is much documentation in the kernel in addition to information on the internet and books that are written every year or so. I think though that there is a fundamental misunderstanding that there is a separation between the kernel and vendors, the kernel is a monolithic project, intentionally without a published internal API that a third party could develop for. One is either a kernel developer or not, regardless of whether they work for one vendor or another or are a volunteer and when you are a kernel developer than you are one small part of a much larger project.

It is great if one can provide long term support for the code they write but there is a presumption that people will move on and that someone else has to be able to fill those shoes. It would be great if hardware makers would allow kernel developers who are not in their employ to see hardware specs and docs it is clearly not a hard requirement otherwise b43 wouldn't exist. There is a long history of drivers being developed without the manufacturers involvement and while the process will be slower and more error prone it is not a show stopper.

As I said before, the kernel developers (which could include Broadcom employees) would rather not have a driver with baggage attached than try and support something out side of their support model. There is nothing stoping Broadcom from being kernel developers, it's a non-exclusive club that many many hardware vendors participate in every day.

In this specific case I hope that Broadcom can convince others that the architecture of their driver is better, not only that it supports more hardware. Certainly they will not be successful in arguing that the architecture of their driver is better because it matches that of some other OS that the Linux kernel developers couldn't give a rats ass about.