Sorry for entering late here. Here are my questions: How does l-m-c know about the boot partition convention? Is the fact that omap wants a dos partition with some files on it but i.MX just needs the raw bits at a fixed location on the card embedded in l-m-c? If a new platform pops up with a completely different convention does l-m-c need to be modified or could we put a script in the hwpack to do that?
For map you could call a script with an argument pointing to the blown out hwpack and and second argument pointing at the mounted boot partition. For mx first argument is the same second is a pointer to raw device. So the hwpack would need a field to say if the scipt needs a raw device or mounted dos partition and.. another field with the script name. Is this over engineering? Sorry for the noise, John On Wed, Jan 19, 2011 at 9:58 AM, Loïc Minier <loic.min...@linaro.org> wrote: > On Wed, Jan 19, 2011, James Westby wrote: >> Right, but what would they do? That's my point. >> >> If you really want to push Andoid in to v2 then we can write code to >> identify/specify image type, then defer Android/linux_image combination >> with a specific error message. >> >> The point of a format specifier is such that l-i-t won't try to act on >> things that are added after that version was released. If the old code >> won't do the wrong thing then we don't need a format bump. > > That's exactly my point: have the next version of the code try to do > the right thing. Maybe I actually have broken expectations: I expect > l-i-t would reject hwpacks with unknown fields. That's the failure > I'm trying to avoid if we know we're going to introduce a linux_image > field and that it can be safely ignored. > > It's a bit like when Debian introduced Breaks, by adding support to > dpkg to simply treat the field in a dumb way, and then adding full > support the next cycle, as to allow using old dpkg for upgrades. > > -- > Loïc Minier > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
