Broadcom's wireless drivers, one year later [LWN.net]

Broadcom's wireless drivers, one year later

Posted Sep 1, 2011 10:02 UTC (Thu) by johannbg (guest, #65743)
In reply to: Broadcom's wireless drivers, one year later by raven667
Parent article: Broadcom's wireless drivers, one year later

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.

to post comments

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.