Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.

[Jeff Garzik <jeff@garzik.org>]

Theodore Tso wrote:
> On Tue, Jul 15, 2008 at 02:44:46PM -0400, Jeff Garzik wrote:
>> All of the regressions examples I am citing are cured by  
>> firmware-in-module, because they are all examples of problems that occur  
>> when you remove the ability to reproduce the same functional pieces as  
>> 2.6.26.
> 
> Jeff,
> 
> 	I think you've said this before, but let me try to help you
> cut to the chase.  You are willing to *implement*
> firmware-in-the-module for request_firmware(), but you want a
> commitment that David Woodhouse and Linus will accept such a patch
> before you go off and write it.  Is that right?
> 
> 	If so, may I suggest you start implementing, instead of
> sending e-mails?  For all the time people have spent arguing about it,
> maybe it could have been implemented already.

Already started, in fact, since Linus said he would not reject it out of 
hands.

Obviously that is not acceptance; I know as well as any that acceptance 
does not occur until the moment of upstream merge.


> 	Once it has been implemented, do you have any further
> objections aka ideas about how request_firmware() could be improved?

Further objections?  None major.

The two other minor problems I feel need solving, but are not related to 
breakage or regressions, are:

1) firmware should be able to live alongside the driver.  We don't need 
to start growing firmware/net alongside drivers/net, firmware/scsi 
alongside drivers/scsi, firmware/char alongside drivers/char, etc.

2) firmware should be able to be shipped in final format (binary), 
rather than ihex.


I feel strongly that 2.6.27 should not be released without 
firmware-in-module, for all the reasons mentioned in these threads. 
It's a major regression, IMO, without firmware-in-module ability.

The other stuff (#1, #2 in list above) is small potatoes.

	Jeff