ELF Parameter Passing....

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