-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Wednesday, April 16, 2008 9:55 AM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: SELF/ELF/LAR
On 16/04/08 07:12 -0600, Myles Watson wrote:
That's where my confusion comes in. Bad ELF files which are parsed
and
added to the LAR cause failures at build time. Bad ELF files
inserted
without being parsed cause failures at boot time.
I prefer Build-time failures to Boot-time failures.
There is no doubt that some parsing has to happen. It is highly
unlikely
that any arbitrary ELF will be optimized for coreboot.
I'm not sure everyone agrees with that statement yet.
Okay, let me put it another way. Its not a guarantee. We might recommend that you use something like libpayload that has a clue, but it it by no means mandatory. So we have to account for the worst case scenario.
The question isn't that it will be parsed, but rather what will the end result of said parse be? The main problem I have with the current scheme is
that
when we move to three or four payloads, I think that managing the segments and walking the lar will become very costly.
I would rather see us go back to a single LAR file per payload. Thats not to say that LAR file wouldn't be pre-processed.
It's usually 3 segments per ELF, right? How many payloads are we
expecting
each ROM file to have? How much time are we talking about?
Again, there is no guarantee. If we embed the name into the .notes section, we have at least 4 segments - possibly even more depending on the complexity of the payload (honestly, most of our payloads today are pretty simple). I would expect that in a typical multiple payload scenario, we would would have at least three payloads - the chooser (bayou), and two payloads to choose from.
Would an extra field in LAR that points to the end of that payload's segments, and a name field suffice? I guess that becomes a small wrapper quickly. What if we kept what we have and added a wrapper (containing a name and a size) at every path separator?
I like the current ability to compress payload segments based on the best compression for that segment. It seems like we lose that if we put ELF files (or a simple alternative) into the LAR without parsing them.
Myles