On Thu, 2008-06-05 at 17:01 -0400, Jeff Garzik wrote:
quoted text
> If the sha1 sum of what is in the kernel tree differs from what the 
> vendor provided, then it is OBVIOUSLY more difficult to verify that
> you have the original firmware as provided by the vendor.
> 
> Put the binary blobs into the git tree, __without modification or 
> wrapping__.

We don't have them in that form right now. Of the firmware blobs I've
encountered so far -- even the ones which were in a file on their own --
none of them are in binary form; they're _all_ in some ASCII
representation which can be processed with 'diff'. That includes char
arrays, arrays of larger integers which need endian-awareness, 'hex
record' structures, and probably a bunch of other abominations I have
yet to encounter as I work through them.

None of them have just been binary files in the source tree.

I do not believe that taking the existing ascii-source representation
and turning it into binary blobs in the source tree is something which
will be unanimously welcomed. But if you prove me wrong, it's trivial to
switch to doing it that way. For example:
	objcopy -Iihex -Obinary firmware/tr_smctr.bin{.ihex,}
	git-rm firmware/smctr.bin.ihex
	git-add firmware/smctr.bin
	git-commit

I'm going to be making a 'shadow' tree containing the result of running
'make firmware_install', just as I have a tree for exported headers.
That tree _can_ have the raw binaries¹. But I don't think it's
appropriate while the firmware is still in the kernel source tree.

-- 
dwmw2

¹ And I plan to make another tree which pulls from that but also includes
  'distributable' firmware blobs, which the owners wouldn't put into the
  kernel tree because of the GPL requirement that would imply.

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