Previous discussion on a boot interface (Pre-RFC: Boot Interface) stalled.
I think one reason for stalling is that there are differences of opinions on exactly what the boot interface should be.
This RFC proposes an alternative that allows for multiple boot interfaces.
Different platforms and systems have different needs for their initial startup / boot time configuration of the kernel.
In particular the specification of untyped memory regions is particularly important.
While there have been discussions on somee options here there is yet to be a strong proposal with widespread support.
One challenge to buiding this support is that it is difficult to build and prototype solution right now.
Additionally, any change has the potential to be disprutive to the ecosystem, which of course reduces the change of any change being accepted.
The function signature for
init_kernel is changed to incorporate a boot protocol version number.
BOOT_CODE VISIBLE void init_kernel( paddr_t ui_p_reg_start, paddr_t ui_p_reg_end, sword_t pv_offset, vptr_t v_entry, paddr_t dtb_addr_p, uint32_t version_dtb_size )
The final parameter
dtb_size is adjusted to include both a version number and the dtb size.
The top four bits of the
version_dtb_size is to be considered the version, while the
lower 28-bits the dtb_size. For example:
uint8_t version = version_dtb_size >> 28; uint32_t dtb_size = dtb_size & 0x0fffffffUL;
This allows for dtb_size of up to 256MiB which should be sufficient in any practical system.
This approach should result in a version of zero for all existing software that uses the current boot interface.
Values 0 through 14 are reserved for official seL4 boot interface version.
Values 15 is avaialble for custom boot interface versions.
This is used, for example, when prototype a new interface or for a fork-specific boot interface.
When handling a different boot interface the kernel may treat the arguments to
For example, it may treat
dtb_addr_p as a pointer to a data structure that conveys additional information between the loader and the kernel.
By itself this doesn’t really do anything.
What it allows for is development of new boot interfaces and the merging of those boot interfaces
in such a way that the kernel can remain compatible with other boot interfaces.
Even in the case where only a single boot interface is used in the kernel at any point in time
this still has the benefit of the kernel being able to check the version between the loader and the kernel.
An alternative is that those experimenting with alternative boot interface can just change the code without worrying about backwards compatibility.
The challenge with this is that coming up with a new boot interface takes some time, and leads to a long lived branch.
The kernel is now moving at a pace where it is preferable to continually rebase/merge against upstream.
This is easier to do when the bulk of code is
new rather than changes to existing code.
An alternative is that we always see the kernel as strongly coupled with the loader, so no version checking would be required.
An alternative is that any change in boot interface is not versioned.