Sorry I've been out of the loop. Here are Stefan's emails and my responses.
As I stated in one of my previous emails, I think that this confusion of having two places where we parse ELF is enough reason to get rid of elfboot in v3.
On Fri, Feb 15, 2008 at 12:50 PM, Myles Watson mylesgw@gmail.com wrote:
ron minnich wrote:
per stefan's comment, let's see how much space we save. This is bootblock space, which could be significant, but can we see a number?
Elfboot still uses bootblock space if it is disabled in Kconfig? That's definitely something we need to fix. That space is tight.
PAYLOAD_NONE doesn't mean no elfboot. Elfboot is included always so that if someone adds an ELF to the lar later it will still work. My contention is that we should make people preparse the ELF when adding it to the lar, so that v3 doesn't have to understand ELF. That doesn't mean that lar shouldn't. Just the opposite.
... as long as they do not remove functionality that is still used.
Please don't just remove this code. If you don't like to compile it in, create a config option to disable it. (There is such a config option already, so I really don't see the gain)
I didn't see one.
I say: NACK.
Why?
Because with this patch it is no longer possible to unpack a lar.
v3 doesn't unpack a lar. lar unpacks them.
Please don't do stuff like that with levity.
Stefan
ron minnich wrote:
Stefan, one thing I don't understand, why does removing elfboot make it so we can't unpack LAR?
Because the LAR header information is lost, things like the entry point.
You unpack it, repack it, and the segments become ordinary files with their lar headers containing bogus information.
So either we recreate an ELF file on unpack, or we dump the metadata to a MANIFEST file.
Or we forget about lars having the feature to be unpacked. Not sure that its ever needed, except when you want to migrate a payload from one image to another one.
This is a lar problem, not a v3 problem.
Stefan.
I hope this clears up some of the confusion. I'm looking forward to understanding your concerns better. I thought this would be an easy choice.
Thanks, Myles