Code isn't interesting anyway; design / architecture is the problem here.
Agreed.
We are all professionals - we can come to a consensus. Right now, we're trying to figure out if we can make ELF perform the way we need it to perform. If we can be satisfied that it can, then we move on. If we cannot be satisfied, then the core team will have to make a decision to move on to another alternative, and then we can debate the details of SELF or something similar.
I agree.
So, what exactly *do* we need here, and *why*?
I think a discussion of where we are and where we want to go would be helpful. Feel free to correct my status summary.
Right now: 1. LAR format supports inclusion of: a. bootblock 1. Can be copied out, but only re-used in same size ROM file b. ELF segments (multiple segments with one entry point, from an ELF) 1. Can't be extracted without losing entry point c. arbitrary blobs 2. Coreboot build process uses the ELF segment idea for a. initram, stage2
I understand that there is resistance against breaking up ELF files for payloads. Does this extend to initram and stage2? Is there another way for the build process?
I'm personally against defining a new file format. I think if we're already going to be parsing ELF in LAR, another format is just another place to introduce bugs.
On extraction: It seems to me that very few end users will want to extract payloads from a ROM. That seems like a task better suited for developers. End users would more likely insert an ELF.
Where we want to go:
I'm unclear on this, because I don't understand the resistance to ELF segments in the LAR.
Thanks, Myles