Messages in this thread | | | Date | Tue, 15 Jul 2008 15:14:20 -0400 | From | Jeff Garzik <> | Subject | Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers. |
| |
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
| |