ELF Parameter Passing....
Eric W. Biederman
ebiederman at lnxi.com
Wed Nov 20 14:36:01 CET 2002
While working on the itanium port of etherboot I have come to the
issue of how best to pass parameters to the newly loaded kernel. What
I would like to achieve is to have a single method that will work for
all situations, not just etherboot.
Currently I have three bootloaders I care about etherboot. kexec
which runs under the Linux kernel. And the ELF loader in LinuxBIOS.
- Ability to pass different pieces of information, as different
bootloaders have different information they want to pass.
- C calling convention for ease of use, and cross platform
- Backwards compatibility. Basically it should be possible to
test to see if you were passed the new parameters instead of
whatever legacy way of passing parameters is present.
- Extensibility. Each bootloader can go their own way and add
additional pieces of information without needing to sync with any
- Ignoreability. It should be legal and even recommended for the
loaded image to ignore the options passed to it, if it has a better
source for that information.
Getting this right is important because on the Itanium, at least when
running under efi I must pass the memory map to the loaded kernel.
What I am thinking is something like:
typedef uint16_t Elf_Half;
typedef uint32_t Elf_Word;
Elf_Word b_signature; /* 0xE1FB007 */
Followed by an array of elf notes.
int entry(Elf_Bhdr *table);
The important parts are passing a single parameter that is a pointer,
so the function signature never needs to change, and for a simple
bootloader everything can be hardcoded. Tagged table entries, which
know their length, so even unknown entries can be skipped. And tags
on the table entries that do not need a central authority to assign.
Plus enough redundancy to see that the passed data is valid.
Roughly this is what I have proposed before for a standard except for
using the C calling conventions.
If there is a better proposal, or something more standard (say what
the open firmware platforms are doing) I am still open to discussion.
But if I don't hear anything this is what I will implement.
More information about the coreboot