On Thu, 2008-06-05 at 18:11 -0400, Jeff Garzik wrote:
quoted text
> Here is my "ideal firmware world":
> 
> * do NOT remove ability to compile firmware into the kernel

I have no intention of removing that.


quoted text
>  (or into a module)

That I don't care about. If you can load modules, you can handle
request_firmware().

quoted text
> * 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.

quoted text
> * 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.

quoted text
> * 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.

quoted text
> * 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.


quoted text
> 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

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/