On 13/04/08 01:18 +0200, Segher Boessenkool wrote:
I'm not going to get into the ELF or not debate. Ron feels passionately about it, and we developed the SELF idea with that in mind. I personally don't care if we use ELF or not, but there are certain issues that we need to make sure are covered:
1) 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.
2) The ELF loader needs to be simple, fast, small, and licensed with BSD so it can be included in libpayload
3) 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.
Right now, SELF satisfies all these requirements.
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. The only requirement is that there only be one ENTRY segment, which is fine, because thats exactly how many entry points we have.
We already know what endianism, word size and architecture we're going to run on - SELF is not intended to be portable. It is constructed when the LAR is, and is married to that LAR and that LAR only. And before somebody says something, yes - this is not fool-proof. Somebody will no doubt manage to screw it up and get the wrong SELF on the wrong architecture. But I don't like over-architecting to protect fools. Worrying about specifying the architecture here is the computer science equivalent of the "Caution, coffee is hot" warning.
Jordan