lkml.org 
[lkml]   [2008]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 00/18] firmware: moving drivers to request_firmware()
From
Date
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



\
 
 \ /
  Last update: 2008-06-06 00:23    [W:0.786 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site