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.
Requirements. - 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 predictability. - 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 universal authority. - 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;
typedef struct { Elf_Word b_signature; /* 0xE1FB007 */ Elf_Word b_size; Elf_Half b_checksum; Elf_Half b_records; } Elf_Bhdr;
typedef struct { Elf_Word n_namesz; Elf_Word n_desc; Elf_Word n_type; } Elf_Nhdr;
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.
Eric