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

Jeff Garzik
2008-07-15T19:14:48Z

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