|
Home > Archive > Debian Developers > March 2004 > Bug#239952: kernel-source-2.6.4: qla2xxx contains non-free firmware
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Bug#239952: kernel-source-2.6.4: qla2xxx contains non-free firmware
|
|
| Herbert Xu 2004-03-25, 6:34 am |
| On Thu, Mar 25, 2004 at 02:21:17AM -0800, Don Armstrong wrote:
>
> 2: I really hope these devices aren't quite so braindead as to not
> work at all if they don't have the firmware loaded by the
> driver... but then again, hardware designers never cease to depress
> me.
In most of these cases the driver cannot communicate with the device
in any meaningful way until the firmware is loaded. The reason is
that they do not contain copies of the firmware in their ROM (if they
have any ROM at all).
However even when the device does contain copies of the firmware in
their ROM, it is probably out-of-date and/or buggy. Therefore in
either case removal of the firmware will render the driver useless.
At best they'll have to go into contrib.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to debian-bugs-dist-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2004-03-25, 12:37 pm |
| On Mar 25, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> However even when the device does contain copies of the firmware in
> their ROM, it is probably out-of-date and/or buggy. Therefore in
> either case removal of the firmware will render the driver useless.
> At best they'll have to go into contrib.
I disagree. The driver is fully functional and should stay in main,
it's the hardware which may not work without until the firmware has been
loaded.
Refusing to distribute firmware files is just hypocrisy, because
everyone of us has some non-free firmware in his own computer.
I also oppose this on practical grounds, more and more essential
hardware wants its firmware to be loaded by the host CPU (because it's
the right thing to do when designing hardware, if it's not needed for
boot the the flash RAM on the device is wasted).
qla2xxx is not the only driver in debian which contains a firmware, BTW.
--
ciao, |
Mneedsarco | [5341 l'm9tNBMIc6Yg]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2004-03-25, 6:38 pm |
| On Mar 25, Roland Stigge <stigge@antcom.de> wrote:
> On Thu, 25 Mar 2004 17:21:44 +0100, Marco d'Itri wrote:
> It's a big difference if we _have_ it (e.g. also microcode in the CPU,
> BIOS, etc.) on our local machine, or if Debian distributes it in binary
> form.
No, there is no difference. Your hardware needs some non-free code to
work, and there is nothing you can do about it. You may choose to
pretend that it does not by removing it from debian, but you will be
still using non-free code.
> The solution here would be to ask upstream for disclosure of source code
Dream on... For a few devices it could happen, maybe. But for many of
them this is not possible. Sometimes because the firmware is a real
RTOS, or because of national regulations or because even the hardware
manufacturer does not have the source.
> and maybe the offer to help with build environment integration. Else,
> (binary) firmware could be provided in non-free packages for hardware
> with buggy firmware. The presence of it could trigger its use. (If
> there's no firmware provided in the device at all, I don't consider it
> "firmware" if it's Debian's turn to provide it.)
You are rewriting the dictionary to support your argument.
--
ciao, |
Marco | [5352 abcjNxYKdMAFY]
| |
| Don Armstrong 2004-03-25, 6:38 pm |
| On Thu, 25 Mar 2004, Marco d'Itri wrote:
> On Mar 25, Roland Stigge <stigge@antcom.de> wrote:
> No, there is no difference.
Wait, let me get this straight:
There's no difference between "having non-free works on a personal
machine" and "Debian distributing distributing non-free works"?
> You may choose to pretend that it does not by removing it from
> debian, but you will be still using non-free code.
I hope no one here is pretending that some hardware may not require
non-free code when in fact it does. The two issues are: 1) Can Debian
distribute the code? [So far, I'm inclined to say no.] 2) Should
Debian distribute the code? [The DFSG leads me to believe no, but I'm
open to being convinced either way.] Clearly, in order for us to
distribute, we need to answer both questions in the affirmative.
>
> Dream on... For a few devices it could happen, maybe. But for many
> of them this is not possible.
It's not that it's not possible, it's that upstream may not want to
disclose the source. There's a huge difference between the two.
The whole point is to attempt to work with upstream to free the
firmware. Quite often it's something that they just haven't thought
about and/or gone through the legal formalities to take care of
it. Regardless, giving up before asking them isn't going to result in
any changes in the situation.
> Sometimes because the firmware is a real RTOS,
I'm not sure at all what the firmware being a RTOS has to do with it's
distributability.
> or because of national regulations
I'm also unaware of any US or CA regulations[1] that would permit
distributing binary firmware but not the source to that firmware.
> or because even the hardware manufacturer does not have the source.
Since QLogic owns the copyright, it would be quite surprising if they
did not also control the source. Obviously, if the manufacturer
doesn't control the source, than we need to communicate with whoever
does.
Don Armstrong
1: QLogic is a California Corporation with headquarters in Aliso Viejo.
--
Democracy means simply the bludgeoning of the people by the people for
the people.
-- Oscar Wilde
http://www.donarmstrong.com
http://rzlab.ucr.edu
| |
| Henning Makholm 2004-03-25, 6:45 pm |
| Scripsit Marco d'Itri <md@Linux.IT>
> No, there is no difference. Your hardware needs some non-free code to
> work, and there is nothing you can do about it.
Has the hardware somehow been designed to not work if it is fed free
code instead of non-free? How on earth does one get circuitry to make
that distinction?
--
Henning Makholm "Grisene fik gåsehud"
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Don Armstrong 2004-03-25, 6:45 pm |
| On Thu, 25 Mar 2004, John Hasler wrote:
> Don Armstrong writes:
>
> The hardware vendor may have licensed the RTOS from a company which
> is in the RTOS business and is therefor very unlikely to free the
> source.
Yes, but that's a case where the firmware contains code that isn't
wholly owned by the manufacturer and not unique to RTOS based
firmware...
> This is likely to be a continuing problem: licensing "IP" under
> _extremely_ restrictive conditions is routine in the hardware
> business.
Yes... it seems to be one which we have to fight against quite often,
unfortunatly.
Don Armstrong
--
I never until now realized that the primary job of any emoticon is to
say "excuse me, that didn't make any sense." ;-P -- Cory Doctorow
http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu
| |
| Marco d'Itri 2004-03-26, 11:20 am |
| On Mar 26, Henning Makholm <henning@makholm.net> wrote:
> Has the hardware somehow been designed to not work if it is fed free
> code instead of non-free? How on earth does one get circuitry to make
> that distinction?
The firmware could be signed, but this is usually not a problem.
The real problem is that there is no pratical way to rewrite from scratch
certain code. (If you don't believe this then please introduce me to
sombody able to write the software which implements DSL modulations and
is not already working for a modem vendor and/or encumbered by NDAs.
And don't forget about the patents either. Obviously he will get no
documentation from the modem chipset producer, so let's look for an
expert in hardware reverse engineering as well.)
--
ciao, |
Marco | [5368 alY2KC5i2yIKU]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-03-26, 3:35 pm |
| Marco d'Itri wrote:
> On Mar 25, Roland Stigge <stigge@antcom.de> wrote:
>
> No, there is no difference. Your hardware needs some non-free code to
> work, and there is nothing you can do about it. You may choose to
> pretend that it does not by removing it from debian, but you will be
> still using non-free code.
Actually, there's a very big difference. It's the difference between
"My system uses non-free code"
and
"The Debian system contains non-free code"
Why is this so hard for some people to understand?
--
Make sure your vote will count.
http://www.verifiedvoting.org/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Humberto Massa 2004-03-26, 4:34 pm |
| Nathanael Nerode wrote:
> If the binary blob was really the source file, then it's fine. For
> these so-called "GPLed" binaries, we should ask the copyright
> holders if they were *really* written as binary blobs. If they say
> "yes", let's believe them. If they say "no", then the binaries are
> undistributable.
Aye to that. This is basically the same I said in the -legal list: as
far as we know, the { 0x... } are magic numbers and this can be the
"preferred form for modification".
--
br,M
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-03-26, 4:34 pm |
| John Hasler wrote:
> Don Armstrong writes:
>
> The hardware vendor may have licensed the RTOS from a company which is in
> the RTOS business and is therefor very unlikely to free the source.
>
> This is likely to be a continuing problem: licensing "IP" under
> _extremely_ restrictive conditions is routine in the hardware business.
I must agree that it's a continuing problem. So the question is: should
Debian abandon its principles in the face of problems, or "remain 100%
free", even when it's quite difficult?
I think you know what line 1 of the Social Contract says. I think you know
what Debian's users demand.
--
Make sure your vote will count.
http://www.verifiedvoting.org/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-03-26, 4:35 pm |
| Marco d'Itri wrote:
> On Mar 26, Henning Makholm <henning@makholm.net> wrote:
>
> The firmware could be signed, but this is usually not a problem.
> The real problem is that there is no pratical way to rewrite from scratch
> certain code.
Which is why it's important that it be available as source code. *sigh*
These are arguments that the freedom of the code matters -- and therefore
arguments against allowing Debian "main" to contain this sort of non-free
code.
> (If you don't believe this then please introduce me to
> sombody able to write the software which implements DSL modulations and
> is not already working for a modem vendor and/or encumbered by NDAs.
> And don't forget about the patents either.
Yes, these are a real danger, since they impinge on independent rewriting.
> Obviously he will get no
> documentation from the modem chipset producer, so let's look for an
> expert in hardware reverse engineering as well.)
Oh, anyone can do hardware reverse engineering; it's "just" an incredible
pain in the neck and takes forever.... ;-)
--
Make sure your vote will count.
http://www.verifiedvoting.org/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2004-03-26, 6:37 pm |
| On Mar 26, Nathanael Nerode <neroden@twcny.rr.com> wrote:
> Actually, there's a very big difference. It's the difference between
> "My system uses non-free code"
> and
> "The Debian system contains non-free code"
>
> Why is this so hard for some people to understand?
As I said, this is hypocrisy.
--
ciao, |
Marco | [5379 agpT76uN2M7tc]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Hamish Moffatt 2004-03-27, 9:34 am |
| On Thu, Mar 25, 2004 at 05:21:44PM +0100, Marco d'Itri wrote:
> Refusing to distribute firmware files is just hypocrisy, because
> everyone of us has some non-free firmware in his own computer.
>
> I also oppose this on practical grounds, more and more essential
> hardware wants its firmware to be loaded by the host CPU (because it's
> the right thing to do when designing hardware, if it's not needed for
> boot the the flash RAM on the device is wasted).
>
> qla2xxx is not the only driver in debian which contains a firmware, BTW.
Yep. Many of the drivers in drivers/media/dvb/frontends also require
firmware. Some included it in the driver (big hex tables) and some like
to load it from the filesystem (including some from Windows DLLs).
I think the DFSG technically requires us to have source for that firmware.
We all know it is really compiled from source code originally in almost
all cases. However, removing those drivers from the kernel packages in
main would make them almost useless, imho.
Some of the removals are already very frustrating to me. acenic is gone
(its firmware was in the source). I notice that upstream linux 2.6.4
contains a rewrite of the e100 driver that no longer loads binary-only
firmware over the firmware built-in to the hardware, but the binary-only
firmware did have a performance advantage over the built-in firmware
which is presumably now lost.
Perhaps we need a set of complete kernel packages in non-free then.
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Matthew Garrett 2004-03-27, 11:34 am |
| Hamish Moffatt wrote:
>Perhaps we need a set of complete kernel packages in non-free then.
The problem is that the GPL requires us to be able to provide the
preferred form for modifications for the entirity of the code.
Realistically, there's no way that the majority of this firmware is the
preferred form for modification. As a consequence, unless we receive an
exemption from every copyright holder in the kernel, we have no legal
right to distribute kernel images with this firmware linked in. What we
can do is provide the firmware separately (non-free is the only
practical place at the moment, but pragmatically an independent section
for firmware would make more sense) and load it from userspace.
--
Matthew Garrett | mjg59-chiark.mail.debian.devel@srcf.ucam.org
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-03-27, 3:36 pm |
| Marco d'Itri wrote:
> On Mar 26, Nathanael Nerode <neroden@twcny.rr.com> wrote:
>
> As I said, this is hypocrisy.
You apparently don't know the meaining of "hypocrisy". Buy a dictionary and
look up "hypocrisy".
If *every* Debian-based system had to contain non-free code, that would be
one thing. (To some extent this is true, but all such code is hardwired
into ROM and Debian has no reason to distribute it at all.) If *some*
hardware requires non-free code, it seems perfectly reasonable to allow
people who have that hardware to have the non-free code, without adding it
wholesale to the collection of code Debian advertises as being "Free".
--
Make sure your vote will count.
http://www.verifiedvoting.org/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Christoph Hellwig 2004-03-28, 5:34 am |
| On Sun, Mar 28, 2004 at 12:36:57AM +1100, Hamish Moffatt wrote:
> (its firmware was in the source). I notice that upstream linux 2.6.4
> contains a rewrite of the e100 driver that no longer loads binary-only
> firmware over the firmware built-in to the hardware, but the binary-only
> firmware did have a performance advantage over the built-in firmware
> which is presumably now lost.
Actually it didn't. Linux upstream and Intel are not Debian, and they
don't really care about your issues here. The firmware was added
because hardware checksum offloading was on the checklist for the
original driver author, and it has been removed now because it doesn't
provide any benefit with modern host cpus but complicates the code a
lot.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Hamish Moffatt 2004-03-29, 10:34 am |
| On Sat, Mar 27, 2004 at 02:24:27PM +0000, Matthew Garrett wrote:
> Hamish Moffatt wrote:
>
> The problem is that the GPL requires us to be able to provide the
> preferred form for modifications for the entirity of the code.
> Realistically, there's no way that the majority of this firmware is the
> preferred form for modification. As a consequence, unless we receive an
> exemption from every copyright holder in the kernel, we have no legal
> right to distribute kernel images with this firmware linked in.
I see your point, but I'm confused by one example. Intel provides the
e100 driver in the kernel source, clearly licensed under the GPL
(there's a whole copy of it in the e100 directory in the kernel tree).
Intel also provides a hex dump of new microcode for the hardware.
Clearly the hex dump isn't the preferred form of modification, but
clearly Intel intends us to be able to distribute kernel images
containing that firmware.... So where does that leave us?
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Hamish Moffatt 2004-03-29, 10:34 am |
| On Sun, Mar 28, 2004 at 12:01:26PM +0200, Christoph Hellwig wrote:
> On Sun, Mar 28, 2004 at 12:36:57AM +1100, Hamish Moffatt wrote:
>
> Actually it didn't. Linux upstream and Intel are not Debian, and they
> don't really care about your issues here. The firmware was added
> because hardware checksum offloading was on the checklist for the
> original driver author, and it has been removed now because it doesn't
> provide any benefit with modern host cpus but complicates the code a
> lot.
This is hardly relevant to the topic, but do you have proof of this?
It looked beneficial in some circumstances to me in some profiling
I did recently.
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Herbert Xu 2004-03-29, 5:37 pm |
| Hamish Moffatt <hamish@debian.org> wrote:
> On Sun, Mar 28, 2004 at 12:01:26PM +0200, Christoph Hellwig wrote:
>
>
> This is hardly relevant to the topic, but do you have proof of this?
> It looked beneficial in some circumstances to me in some profiling
> I did recently.
If I were you I'd take hch's word on this.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Christoph Hellwig 2004-03-30, 12:35 pm |
| On Tue, Mar 30, 2004 at 12:22:12AM +1000, Hamish Moffatt wrote:
>
> This is hardly relevant to the topic, but do you have proof of this?
> It looked beneficial in some circumstances to me in some profiling
> I did recently.
http://groups.google.com/groups?q=e....bofh.it&rnum=2
an additional update from Jeff is "avoidance of e100 hardware checksumming
features is, unfortunately, the only way to guarantee data integrity on all
e100 hardware"
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|