Worth a read [LWN.net]

Worth a read

Posted Aug 31, 2011 11:34 UTC (Wed) by patrick_g (subscriber, #44470)
In reply to: Worth a read by fb
Parent article: Broadcom's wireless drivers, one year later

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

to post comments

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.