linux-kernel - Re: [bug?] tg3: Failed to load firmware "tigon/tg3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 04 Jul 2008 09:39:36 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	David Woodhouse <dwmw2@...radead.org>
CC:	Andi Kleen <andi@...stfloor.org>,
	David Miller <davem@...emloft.net>, tytso@....edu,
	hugh@...itas.com, akpm@...ux-foundation.org,
	kosaki.motohiro@...fujitsu.com, mchan@...adcom.com,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	netdev@...r.kernel.org
Subject: Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"

David Woodhouse wrote:
> On Fri, 2008-07-04 at 09:15 -0400, Jeff Garzik wrote:
>> However, there is still a broken element to the system:  the firmware no 
>> longer rides along in the module's .ko file.  That introduces new 
>> problems for any user and script that copies modules around.
>>
>> The compiled-in firmware should be in the same place where it was before 
>> your changes -- in the driver's kernel module.
> 
> No, Jeff. That is neither new, nor a real problem. You're just
> posturing.
> 
> That's the way it has been for a _long_ time anyway, for any modern
> driver which uses request_firmware(). The whole point about modules is
> _modularity_. Yes, that means that sometimes they depend on _other_
> modules, or on firmware. 
> 
> The scripts which handle that kind of thing have handled inter-module
> dependencies, and MODULE_FIRMWARE(), for a long time now.

You have been told repeatedly that cp(1) and scp(1) are commonly used to 
transport the module David and I care about -- tg3.  It's been a single 
file module since birth, and people take advantage of that fact.

Therefore, logically, you have introduced additional dependencies and 
regressions into what was once a single-file copy.

If you wish to hand-wave away what developers and users do today as 
posturing, that's up to you...

How difficult is it to see that you must create a system that LET'S 
PEOPLE CHOOSE whether or not they like your stuff.

Why are you so hell-bent on removing choice?

Why is it so difficult to see the value of KEEPING STUFF WORKING AS IT 
WORKS TODAY?

Doing so (a) keeps developers happy, (b) GUARANTEES no regressions, and 
(c) in no way excludes /lib/firmware, moving firmware to userspace.

Sheesh.

Let developers, users, and distros endorse your plan on their own 
schedule.  Stop forcing your choices down our throats.

	Jeff

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/