Worth a read [LWN.net]

Worth a read

Posted Aug 31, 2011 17:18 UTC (Wed) by daglwn (guest, #65432)
In reply to: Worth a read by fb
Parent article: Broadcom's wireless drivers, one year later

> In a year from now, I bet we'll have 'another LWN kernel conference
> converage' where Linux devs complain that vendors don't try to work along
> with them.

Right on. Maybe merging the Broadcom driver is not the right thing to do but dismissing it out of hand like this is exactly the wrong attitude to take.

In the end, the Linux kernel needs the vendors more than the vendors need the Linux kernel. Reasonable engineering discussion and decision is productive. Ideological intransigence is not.

to post comments

Worth a read

Posted Aug 31, 2011 18:27 UTC (Wed) by marcH (subscriber, #57642) [Link] (6 responses)

> In the end, the Linux kernel needs the vendors more than the vendors need the Linux kernel.

This used to be true. If it still were, Broadcom would not even be here with brcmsmac. There are market reasons why they changed attitude.

Worth a read

Posted Aug 31, 2011 20:38 UTC (Wed) by TommyAtkins (guest, #79496) [Link] (5 responses)

There are still lots of Broadcom chips which don't have open source drivers, and they are not unusual in this. The kernel may have considerable sway in the market for PC chips, but this is not the case in the embedded market. Also, if the kernel development model becomes too painful, chip vendors can regain control by moving code into the device firmware.

Worth a read

Posted Aug 31, 2011 21:55 UTC (Wed) by marcH (subscriber, #57642) [Link] (4 responses)

> The kernel may have considerable sway in the market for PC chips, but this is not the case in the embedded market.

The embedded market is rather the "embedded marketS", and some are no different from the server market in this respect. Example: how many ARM platforms not supporting Linux?

> Also, if the kernel development model becomes too painful, chip vendors can regain control by moving code into the device firmware.

I doubt this would happen. Running more firmware usually requires more silicon, which costs money on a per-chip basis. As seen in this discussion Linux development can be costly too but since it is software it's a once off.

Worth a read

Posted Aug 31, 2011 22:14 UTC (Wed) by TommyAtkins (guest, #79496) [Link] (3 responses)

> how many ARM platforms not supporting Linux?

How would anyone other than ARM know that?

> Running more firmware usually requires more silicon, which costs money on a per-chip basis. As seen in this discussion Linux development can be costly too but since it is software it's a once off.

That trade-off only works in linux's favour if you are paying for the core which runs your firmware, but not the one running linux. If you are SoC vendor, it's the same either way. Or even in favour of *not* putting the code in linux, under some circumstances...

Worth a read

Posted Aug 31, 2011 22:34 UTC (Wed) by marcH (subscriber, #57642) [Link]

> How would anyone other than ARM know that?

I am sure you can make a good guess.

> That trade-off only works in linux's favour if you are paying for the core which runs your firmware, but not the one running linux. If you are SoC vendor, it's the same either way.

IP blocks making a SoC are designed by different teams, sometimes even different companies, each trying to minimize its corresponding cost. And the cost of running a slightly more complicated driver on the main CPU is usually zero.

If you look in history I think you will see that the cases where hardware takes more features on board are only driven by performance concerns.

PS: A large number of chip designers do not care a bit about any hardware/software trade-off. If they can push stuff to software to save money they will do it.

Worth a read

Posted Aug 31, 2011 23:21 UTC (Wed) by Julie (guest, #66693) [Link] (1 responses)

How would anyone other than ARM know that?

Would ARM actually know this? Don't they just sell IP cores to SoC developers/vendors? I thought kernel contributions were the Soc/platform vendors' responsibility after that. Isn't that part of the problem with code duplication - that they don't like to admit that rival vendors exist (or at least their PR departments don't)?

(I'm sure that there was a Thomas Gleixner article about this not too long ago but I can't find it now in the archives or remember the heading - if anyone has the link that would be great.)

Worth a read

Posted Sep 9, 2011 14:44 UTC (Fri) by wookey (guest, #5501) [Link]

Quite. Arm sell designs, 2nd parties use those to make chip designs, and 3rd parties then use _those_ to make platforms. So ARM itself has no real handle on how many actual board designs/platforms there are out there or what software is running on them. It does get data on chip shipments so royalties can be paid, but that's the closest it gets to knowing what's being done.

And yes - this diversity and the independence of downstream companies/devs is a big part of the reason for the code duplication in the kernel. Organisations like Linaro are doing their best to re-centralise/co-ordinate and share the actual development precisely because the downstream widget-makers and SOC vendors have done such a poor job of upstreaming and not NIHing. (I quite understand why - I use to be a downstream engineer and I failed miserably to get most of my code into mainline too, even though I know perfectly well why it's a good idea).