I'm not going to get into the ELF or not debate.
FWIW, neither am I. I have no stake in this ELF vs. SELF "battle"; the only thing I'm trying to do here is to make sure the final decision is based on correct information.
- We cannot depend on the payload writer to do the right thing. All
we can ask for is a ELF file. If there is post processing work that needs to be done, we need to do it ourselves.
And the "post-processor" can either write SELF, or an ELF with restrictions (PHDRs have to come early, for example). It's about the same thing: you have to use the linker in the same way either way, to arrive at the orignal ELF file. And then you post-process it in such a way that it will be easier/nicer to load in the coreboot environment.
The main difference between the formats AFAICS is that ELF is an old, well-defined, well-understood, matured format, while SELF is a hacky new thing that looks really simple now. My fear is that it will turn out it needs some of the features of ELF later on, and it might not be feasible to put those in in a nice way anymore by then.
- The ELF loader needs to be simple, fast, small, and licensed with
BSD so it can be included in libpayload
Sure, it's just a tiny piece of code either way, so I don't see this issue as an issue.
- We need a equivalent solution for the NAME segment in SELF - the
payload chooser must be able to get a human friendly name for each payload without decompressing the entire payload into memory.
If you want this name to be part of the binary (and we can discuss endlessly whether that is a good idea or not -- let's just accept the answer is "yes" :-) ), for ELF, you would do this using a PT_NOTE normally. It's easy to make sure that note sits at the start of the file, too.
As far as I can see, SELF saves about 100 bytes over ELF, at the cost of a lot of flexibility (only one code/data/bss/notes section, to start with), and a bunch of important header data is missing, too (endianness, word size, architecture).
You can have as many code/data/bss/notes sections as you wish.
Oh, good.
The only requirement is that there only be one ENTRY segment, which is fine, because thats exactly how many entry points we have.
Would it not make sense to put the entry point info in the file header, not in a segment header, then?
We already know what endianism, word size and architecture we're going to run on - SELF is not intended to be portable.
It is nice to have a file header that describes the basic format of the file. You don't *have* to check it if you do not want to.
One important case where you actually want to *use* this info is when you have an architecture that can execute both 32-bit and 64-bit programs.
Segher