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  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 <>
To:	David Woodhouse <>
CC:	Andi Kleen <>,
	David Miller <>,,,,,,,,
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 

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


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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists