On Sun, 2008-04-13 at 04:54 +0200, Peter Stuge wrote:
On Sun, Apr 13, 2008 at 04:39:24AM +0200, Segher Boessenkool wrote:
My current thinking is that since you will have an intermediate ELF file anyway, that you will transform into a SELF file (which has some nice properties), that it would be easier and way more future-proof to transform that intermediate ELF file into a final ELF file (FELF?) with those same nice properties (junk removed, PHDRs and notes at the start -- did I forget any?)
I had the same thought.
There is one rather big disadvantage however, that comes from *almost* supporting a given format. There is some value in having a new, explicit, file format even if it is just a subset of another, existing, file format.
The benefit is in usability and principle of least surprise. If coreboot supports loading certain ELF files, it will be surprising to (some) users if it does not support loading all ELF files.
I'm not sure if this is the right thread but I need to get this out of my head before I forget (i've got about 30 seconds)
I was thinking about legacy removal, and how some payloads need things tweaked for 1980's PC, (filo legacy IDE ports?) and I was thinking that the payload could have a flag saying "hey i need old IDE ports" or something. Coreboot can either flip that feature on, or emit a message.
Other flags are possible, like I need amd64 or FPU or something else.
Doesn't ELF have some fields already that could be used for that?
For the same reason we may also want another name less similar to ELF, to clearly show that it is not an ELF file.
That marking could also say "Linuxbios i386 executable", addressing that issue.