Messages in this thread | | | Subject | Re: [PATCH 00/18] firmware: moving drivers to request_firmware() | From | David Woodhouse <> | Date | Sat, 31 May 2008 23:18:57 +0100 |
| |
On Thu, 2008-06-05 at 18:11 -0400, Jeff Garzik wrote: > Here is my "ideal firmware world": > > * do NOT remove ability to compile firmware into the kernel
I have no intention of removing that.
> (or into a module)
That I don't care about. If you can load modules, you can handle request_firmware().
> * firmware should be field-replaceable, even if one was compiled in
That would be a useful thing; currently the built-in firmwares cannot be overridden but it wouldn't be hard to implement. Suggest it in 'diff -u' form and it might just happen.
> * the preferred form of firmware is one or more binary blobs, stored in > a regular [filesystem|git] binary file.
I don't think we have consensus on that, but as I said: post patches and let's see if they get merged.
> * the preferred form is NOT ascii C source, or any other format other > than the native format that the hardware wants. Remember, the vendor > only provided an ASCII-ized firmware because our system required it that > way, not because that's the preferred form.
And binary isn't the preferred form either. We can cope with binary, but it's not appropriate in the kernel source tree, imho.
When I make the shadow tree which contains the results of 'make firmware_install', that'll have the binaries.
> * in-tree firmwares should be stored in one or more binary files in the > tree, not in C source code or .ihex files. > > * when firmware is stored as binary blob, it is easier for > (1) vendor to replace, > (2) developer/user to compare/verify using sha1, > (3) does not require a C compiler or binutils to unpack
All these are true, but you're still missing the point that as I have it it's already a _lot_ easier to process than when it was arrays of __be32 in some header file. I don't want to change to binary blobs as part of what I'm doing this week. That's a _separate_ issue, and I'm not even sure it's a goal I agree with.
> Thus, if you are going to be touching the in-tree firmwares at all, it > doesn't make sense to convert from C source to any format other than > native binary.
I disagree. But feel free to post patches which get applied and prove me wrong. I'm not going to object if you want to go convert a few more drivers.
-- dwmw2
| |