Message-ID: <4848489C.6010903@garzik.org>
Date: Thu, 05 Jun 2008 16:12:12 -0400
From: Jeff Garzik <jeff@garzik.org>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: David Woodhouse <dwmw2@infradead.org>
CC: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/18] firmware: moving drivers to request_firmware()
References: <20080605.foo@pmac.infradead.org>  <48483BA9.1070200@garzik.org> <1212695675.32207.288.camel@pmac.infradead.org>
In-Reply-To: <1212695675.32207.288.camel@pmac.infradead.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1219
Lines: 34

David Woodhouse wrote:
> On Thu, 2008-06-05 at 15:16 -0400, Jeff Garzik wrote:
>> Why do we need the .ihex format?
>>
>> We should be loading firmwares exactly as they come from the vendor, 
>> without any wrappers.
> 
> It's just 'objcopy -Ibinary -Oihex foo foo.ihex'. It's purely for
> convenience of handling the binary blobs in git (and it means we can
> append licensing information after the EOF record too, if we want).

Well, I should ask, is this purely an internal build detail?

The developer (and user) should never ever see a .ihex file, outside of 
an active kernel compile.  Wrapping the original firmware makes it more 
difficult to verify, compare and/or change.  In-tree, we should see the 
vendor firmware blobs as shipped, with no wrapping or modification or 
anything.

Any metadata can be added as a separate file.

If .ihex is purely a temporary thing during compile, no big deal, ignore 
me.  Otherwise, that's something we should avoid.

	Jeff


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