Worth a read [LWN.net]

Worth a read

Posted Aug 30, 2011 15:59 UTC (Tue) by corbet (editor, #1)
Parent article: Broadcom's wireless drivers, one year later

Here's a response from Henry Ptasinski that hadn't been posted when the article was written; he describes the advantages he sees in the brcmsmac driver over b43. What's going to hurt, though, is this statement:

The brcmsmac driver has architectural alignment with our drivers for other operating systems, and we intend to to enhance and maintain this driver in parallel with drivers for other operating systems. Maintaining alignment between our Linux driver and drivers for other operating systems allows us to leverage feature and chip support across all platforms.

That is not an approach that flies well in the kernel community; Linux drivers should be Linux drivers. This "architectural alignment" can only be maintained for as long as Broadcom keeps control over the driver, and control is one thing that is hard to have in the free software world.

to post comments

Worth a read

Posted Aug 30, 2011 17:06 UTC (Tue) by rahvin (guest, #16953) [Link] (6 responses)

I'd wager that comment alone killed any chance of the driver ever being accepted. As you said, similar comments by other companies in the past got their code blackballed.

Cross-platform drivers

Posted Aug 31, 2011 8:30 UTC (Wed) by mjthayer (guest, #39183) [Link] (5 responses)

> I'd wager that comment alone killed any chance of the driver ever being accepted. As you said, similar comments by other companies in the past got their code blackballed.

Warning: the following complaining is going to be slightly off-topic. This brings back memories of another recent LWN article [1]. And it makes me feel, once again, that the kernel community are a bit too unforgiving or inflexible in their insistence on things being done exactly their way. Of course I understand and sympathise with their arguments that they can avoid lots of unnecessary duplication between drivers for different hardware, as avoiding duplication generally raises software quality (while lowering costs). But sharing driver code between different operating systems is also avoiding duplication, and I think that if the kernel community wanted to they could help vendors produce drivers which go some way towards achieving both. Or is there a feeling that this is giving unneeded (since the community has the resources to manage without vendor drivers) help to the competition?

I must note that I am somewhat biased as I work among other things on the cross-platform driver code of the VirtualBox Guest Additions (which we are not likely to try to get upstream in the foreseeable future).

[1] http://lwn.net/Articles/454716/

Cross-platform drivers

Posted Aug 31, 2011 12:19 UTC (Wed) by vonbrand (guest, #4458) [Link] (3 responses)

You just have to consider that the work load considered by kernel hackers is their burden, if lightening theirs means others have to work more, so be it.

Cross-platform drivers

Posted Aug 31, 2011 13:01 UTC (Wed) by mjthayer (guest, #39183) [Link] (2 responses)

> You just have to consider that the work load considered by kernel hackers is their burden, if lightening theirs means others have to work more, so be it.

Certainly, but does sharing code (in a sensible way of course) with other platforms make that burden heavier?

Cross-platform drivers

Posted Sep 1, 2011 21:08 UTC (Thu) by mlankhorst (subscriber, #52260) [Link] (1 responses)

I'd like to point you to an article 2 weeks ago in lwn

https://lwn.net/Articles/454716

Cross-platform drivers

Posted Sep 2, 2011 8:12 UTC (Fri) by mjthayer (guest, #39183) [Link]

> I'd like to point you to an article 2 weeks ago in lwn

I actually quoted that myself a couple of posts up this thread!

Cross-platform drivers

Posted Aug 31, 2011 15:54 UTC (Wed) by bronson (subscriber, #4806) [Link]

I haven't seen Linux developers worry about helping the competition (with one notable Reiser exception). This might be partly GPLv2 smugness ("go ahead, I'll just poach your changes when you release them") but I think it's just focusing on what's important. Rather than crying about calling something Linux/Android or aligning marketing messages, kernel devs just keep improving their piece of the universe.

As for the Broadcom driver, who wants to maintain another 4 files of useless shims? Or merge a do-nothing patch that contains changes needed by the Win32 ARM driver? Or try to navigate a mess of invisible dependencies known only to Broadcom devs? That would be madness.

So, I think the reservations of the kernel devs are 100% practical. They're just maximizing the maintainability of the Linux driver.

If Broadcom wants to release the source to all their other drivers too, then I expect the Linux kernel crew would be willing to talk about code duplication. Until then, they can only work with what they know.

Worth a read

Posted Aug 31, 2011 9:48 UTC (Wed) by fb (guest, #53265) [Link] (18 responses)

> > Maintaining alignment between our Linux driver and drivers for other operating systems allows us to leverage feature and chip support across all platforms.

Sounds like a very reasonable argument from my point of view.

> That is not an approach that flies well in the kernel community; Linux drivers should be Linux drivers.

Oh, but you see, sir, "Linux drivers should be Linux drivers", we only care about duplication inside the kernel itself. We actually encourage, or should I say, demand duplication in a vendor's own software projects.

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.

Worth a read

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

> Oh, but you see, sir, "Linux drivers should be Linux drivers", we only care about duplication inside the kernel itself. We actually encourage, or should I say, demand duplication in a vendor's own software projects.

Thanks for the quote of the week.

Worth a read

Posted Aug 31, 2011 11:34 UTC (Wed) by patrick_g (subscriber, #44470) [Link] (8 responses)

>>>Sounds like a very reasonable argument from my point of view.

Have you seen this mail from Greg KH in the thread? IMHO he asked very good questions and the "reasonable argument" made by Broadcom devs was destroyed.

Worth a read

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

> the "reasonable argument" made by Broadcom devs was destroyed.

... and they were so "destroyed" that they did not even answer.

More seriously, I suspect Greg's GPL comment is off-topic: "architectural alignment" does not sound like sharing code.

Greg's maintenance concern is likely to be moot as well. As an adaptation layer a driver like this one has two "sides": a low-level side interfacing with the hardware and, a high-level side interfacing with the operating system. Now guess which side Broadcom wants to keep "architecturally aligned" across operating systems?

Worth a read

Posted Aug 31, 2011 13:20 UTC (Wed) by fb (guest, #53265) [Link] (2 responses)

> Have you seen this mail from Greg KH in the thread? IMHO he asked very good questions and the "reasonable argument" made by Broadcom devs was destroyed.

IMHO the Broadcom devs argument remains reasonable.

Collaboration needs to happen both ways. They are willing to provide a driver, clean it and maintain it, and I find it reasonable for the kernel to takes steps to make that practical for them as well. Keep in mind that the code released by Broadcom lead to improvements to the kernel's own b43 driver.

Let them maintain that driver alone, or make outside contributions, say, Apache/GPL licensed. (Isn't it the case that when Linux took code from a BSD kernel, people decided that it should remain dual licensed?) GKH implicitly assumes that a dual-license for their OS independent code is impossible. That is precisely we demand code duplication at your company's side.

Kernel devs asking companies (managers & coders) to work along with them should understand that these folks also have other constraints in life than the Linux kernel.

Worth a read

Posted Aug 31, 2011 14:20 UTC (Wed) by corbet (editor, #1) [Link] (1 responses)

The improvements to the b43 driver are unproven at this point. They may well exist, but I would not just assume that they exist.

You're suggesting that we take drivers into the tree under the condition that only the vendors can modify them? We've seen that idea in the past; it doesn't work well at all. If it's free software, it needs to be free, not under vendor control. And that's before you consider that vendors always lose interest in drivers long before customers stop using the hardware. Remember that kernel developers need to think about what it's going to be like to maintain the code five or ten years into the future.

Sounds like I need to write another article :)

Worth a read

Posted Aug 31, 2011 15:50 UTC (Wed) by fb (guest, #53265) [Link]

I had understood that b43 (1) had been improved (2) by making use of the Broadcom driver, now I see that I need to brush my reading comprehension... say:

> Rafal doesn't say whether the brcmsmac driver was helpful to him in filling out hardware support in the b43 driver.

[...]

What I was suggesting though is to have (non-Broadcom) kernel devs making their contributions, say, Apache / GPL on this driver (instead of requiring Broadcom to duplicate their own stack), or (indeed) just let them maintain that themselves. Of course that only goes for as long as Broadcom is answering promptly to issues.

> Sounds like I need to write another article :)

Please do, your articles are always remarkably informative (even when I don't read them properly). However some themes get repeated often at LWN, like: kernel devs at conference XYZ ask hardware vendors to work closer to the community instead of just dumping crappy code on an FTP server.

Worth a read

Posted Sep 1, 2011 12:30 UTC (Thu) by SLi (subscriber, #53131) [Link] (3 responses)

Argh, I had missed that again, and I blame solely the way LWN links to the mails on LKML.

Why on earth is it that

1) Every link to a mail on LKML on LWN shows that mail as the root of the thread

2) The threads seem to always be otherwise incomplete in a number of different ways

I believe there are good web frontends to LKML. Why always link on one that is so horribly broken?

Worth a read

Posted Sep 1, 2011 15:30 UTC (Thu) by nix (subscriber, #2304) [Link]

The first symptom is just the way gmane works: if you want to see the whole thread, click on the subject line. The threads are very rarely incomplete in my experience: gmane has good connectivity.

A lot of people likely read l-k via gmane, and if it was receiving only a partial feed, people would already have complained. It's probably your setup. (What web browser are you using?)

Gmane

Posted Sep 1, 2011 15:43 UTC (Thu) by corbet (editor, #1) [Link] (1 responses)

We link to gmane for one very simple reason: it can be done in an automated way. If we had to fish out links manually for every message we post, it simply would not happen at all. The gmane interface is a little funky at times, but it works well enough once you get the hang of it.

Gmane

Posted Sep 1, 2011 16:44 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

Would be nice to see the LWN codebase become Free software. This is the sort of minor things that others could reuse in various places.

Worth a read

Posted Aug 31, 2011 17:18 UTC (Wed) by daglwn (guest, #65432) [Link] (7 responses)

> 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.

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).

Worth a read

Posted Aug 31, 2011 11:05 UTC (Wed) by marcH (subscriber, #57642) [Link] (2 responses)

> ... and control is one thing that is hard to have in the free software world.

For good and bad, the development of Linux drivers is MUCH more controlled than for other operating systems. Not an opinion, just a fact.

Worth a read

Posted Aug 31, 2011 13:05 UTC (Wed) by tzafrir (subscriber, #11501) [Link] (1 responses)

Controlled by whom?

Who controls the Broadcom drivers for other operating systems?

Worth a read

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

> Controlled by whom?

Definitely a key question. Control is felt only when you do not have it.