On Wed, 19 Jan 2011 02:02:57 +0100, Loïc Minier loic.minier@linaro.org wrote:
Hey thereAs a result of a series of bugs around linaro-image-tools and daily images, it seemed a sensible approach to solve this class of issues would be to move more data into hardware packs rather than hardcoding stuff in linaro-image-tools.
Guilherme, Steve Langasek, and Michael Hudson were all interested in the idea, so Michael convinced me to start a wiki page with some notes: https://wiki.linaro.org/Platform/Specs/11.05/HardwarePacksV2
I'm sending this for others to get the chance to raise issues with hwpacks since we don't want to change the format too frequently.
Hi,
I think that this is the right direction to be going in, I just have a few comments on the implementation plan.
Would in general be nice to deal with other image types like Android and ChromeOS and avoid .debs unless targetting Ubuntu images.
I think this is the wrong aim to be putting in the document. I think that the aim should be to be able to produce hardware packs that can be shared between Ubuntu, Android and ChromeOS images, and leave the implementation of that as a separate question.
cmdline
Is this going to be a static string, or will it need to substitute variables in to it as it is used?
omap_mlo
I think it's generally better to not put strings like "omap" in the name, and rather have a list of files that will have the same treatment (in this case copy to the boot disk)
igep_uboot_ini
Similar for this (list of files to create)
fdt
What would we do with this if we found it in a hwpack?
linux_image
I don't think there's any point in ignoring this now, and then doing something with it later. It should have a hwpack format bump so that users can be told that they need a newer l-m-c, otherwise when we first release Android hwpacks people will generate unbootable images.
We should only aim for forward compatibility where we know what we will do with the option when it exists. I have no problem not using all options, but unless we know what to do with an option we should not put it in the format, as we will need a format bump when we do know what to do with it anyway.
Thanks,
James