I don't understand why more commodity hardware companies aren't doing this. Drivers are an actual competitive advantage with 3D video cards and possibly a few other things, but I can't see it for wireless chipsets. It seems to me that making the drivers open source might actually reduce costs, with no real down sides.
3D video cards are a commodity, too, these days. Even they could offer open-source reference drivers that allow for full basic utilization of the hardware, albeit at suboptimal performance. The heavily-optimized trade secret like cool codepaths could be offered in binary drivers for those who want the last drop of perf.
The business problem of open source 3D drivers lies not so much in secret know-how in the drivers but in this: http://steveblank.com/2009/04/16/supermac-war-story-7-buildi... High-end graphics cards tend to be exactly same as consumer level cards, save for few bits in some configuration memory that is used by driver to disable more advanced features/reduce performance.
It is. Making a new chip is very very expensive, but copying it is cheap. People demand millions of low end systems but only thousands of high end.
What companies do is use mass production for lowering the price not only of their low-end chips but high end too. They just disable and don't test the "advanced features" in low end cards.
With drivers you could enable it. Some blocks could be damaged(as it was not tested) but as a much lower price you just can buy new cheap ones.
It is relevant; people are "softmodding" GeForces into Quadros, theoretically costing Nvidia millions in revenue. Open-source drivers might make this even easier.
I struggled with vendor drivers for chipsets for years (yes this company too). They are generally awful. Most are warmed-over demo drivers from the original silicon vendor, intended to exercise chip features but no diligence to adhere to specs, protocols, handle (any) error conditions, be readable or supportable.
Vendor "support" for their driver means a third-string intern/student who hashes together patches that reveal profound ignorance of the architecture.
Its not just NIH; the chain of custody from silicon designer to you just doesn't include ANYBODY who has your interests/your customer's interests in mind. They are more concerned with making the driver portable across their product line, doing it cheaply, getting it to market at the same time their hardware releases etc.
Any robustness/architecture/responsible software processes have to be your business and yours alone. This probably means rewriting the whole driver, using the demo driver for reference but ONLY for chip-specific info.
I agree completely with what you said (e.g. the BCM5700 driver was rewritten as tg3), but in this case it's much better to have a crappy vendor driver than to have nothing from the vendor, which was the situation yesterday.
I'm looking at the source and the code that interfaces with the PHY has had every single comment stripped out of it. I don't see the point of that, it'll just take a bit longer for the code to be understood... after all, these guys have even black-box reverse-engineered many NICs.
Unfortunately, it looks like the new driver only supports 3 chipsets, and none of the "older" SSB-based ones. Granted, it's a new driver, and they say it's designed with the idea that other chipsets can be added, but it's still a little disappointing.
(I say "older," because my BCM4322 is such a chipset, and it's in my 15-month-old MacBook Pro. How is that "old?")
Regardless, whatever their motivations, it's a nice start. I wonder if they plan to collaborate with the guys working on the b43 driver at all. They support a ton of chipsets, and (at least from my perspective) the main deficiency is the not-yet-finished (partly due to the reverse-engineering effort being incomplete) N-PHY support for the 11n chipsets.
I feel like there has got to be a gotcha or two in there, but if not, this is great news. I wonder how much the proliferating netbook market is to blame for it?
I agree with you, but if I had to choose between a functional Linux driver and documentation, even as someone running BSD, I would take the Linux driver every time. A functional driver with source lends some confidence that nothing is missing. Documentation can be well-intentioned, but it is rarely so complete that you could write a major piece of software with nothing else.
Of course, drivers+documentation would be even better :)
