Broadcom's wireless drivers, one year later

Posted Aug 31, 2011 21:33 UTC (Wed) by raven667 (subscriber, #5198)
In reply to: Broadcom's wireless drivers, one year later by johannbg
Parent article: Broadcom's wireless drivers, one year later

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.

to post comments

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.