Support passing multiboot modules and command line to rootserver about sel4 HOT 5 OPEN

The ELF loader supports passing the device tree that was passed to it from a previous boot loader instead of the device tree from the CPIO archive.

x86 isn't loaded by the elfloader and doesn't use device trees. I think passing multiboot modules and command line to rootserver is a lot more achievable now that the seL4_BootInfo_t has the extra region support. This is already used to pass through other multiboot info such as the mmap and VESA frame buffer information but using it for multiple user binaries would be interesting to try. It'd be similar to the existing approach of a CPIO archive in the root but would mean more flexibility in being able to change the user apps without relinking the root.

from sel4.

Hi @Oficerx, could you please provide more context?

from sel4.

Hi @Oficerx, could you please provide more context?

Hi,
I mean passing data from bootloader to userland, like executable images, command line, which later could be accessed by rootserver, through BootInfo structure.
Kernel currently supports only one monolithic executable making entire userland, which is constructed during build process. This makes it difficult to add/remove components or alter system behaviour later, as it requires recompiling.

from sel4.

It would certainly be neater than "attach a cpio blob to the root server". 😃

There was some discussion about this on the mailing list last month.

from sel4.

The ELF loader supports passing the device tree that was passed to it from a previous boot loader instead of the device tree from the CPIO archive. Ideally, we would simply pass both device trees here to userland in the boot info, then it could choose what to do with this.
For a command line we could simply use the same was it is done one Linux. Take this from the device tree.

chosen {
        bootargs = "console=ttyO0,115200 root=/dev/mmcblk0p2 rootfstype=ext3 rw rootwait";
        stdout-path = &uart0;
    };

To avoid conflicts with LInux, another name besides bootargs could also be used here - in the end this is up to the userland root task to pick something here and process this.

Can we close this?

from sel4.