> * firmware should be field-replaceable, even if one was compiled in

If you want to replace it then put it in the file system. You've said
binuntils isn't acceptable in your "vision" below so field replacing
compiled in ones clearly is. It's a needless overcomplication.

quoted text
> * the preferred form of firmware is one or more binary blobs, stored in 
> a regular [filesystem|git] binary file.

That depends on the firmware. In a few cases we even have firmware source
in the tree.

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,

Nope, they can't submit a diff to the tree except as an attachment which
will be dropped if you do that. 

quoted text
> 	(2) developer/user to compare/verify using sha1,

sha1 doesn't appear to be totally secure for that purpose with a firmware
block any more. Putting the sha1 in the header might be a good idea in
some cases (eg DaveM wants to be sure precisely *which* tg3 firmware he
loads)

quoted text
> 	(3) does not require a C compiler or binutils to unpack

Why ? What is the usage scenario ? Vendor distributed firmware for PC
class systems is going to be a deb or rpm that drops files
into ../lib/firmware.

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.

You don't mean native binary either. Native binary on some of these
devices is very strange indeed. Its simply bytes in various random
formats for stuffing into the device in various random ways - that's not
really "native" in all cases.

Alan
--
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/