-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Wednesday, April 16, 2008 10:26 AM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: SELF/ELF/LAR
On 16/04/08 10:02 -0600, Myles Watson wrote:
-----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.
I totaly agree - and SELF reflects that behavior without the additional LAR segments. I'm not even sure if Segher is promoting just tossing it into the LAR without parsing, but I don't want to put words in his mouth.
Here's my opinion based on the discussion so far:
I like the idea of SELF except as a file format. I think SELF should stay internal to LAR. With the information in SELF we can create a valid ELF file at extraction time. That way we only have one way to get a Payload into LAR (parsing an ELF) and one way out. Coreboot code only needs to know about the SELF format, and we have many fewer code paths to test and maintain.
My fear was that LAR was going to need to parse ELF and SELF, and so was Coreboot. I think at least one of those pathways would bit rot quickly.
Myles