Hello Peter, I totally agree. We are developing a unikernel (https://github.com/hermitcore/rusty-hermit). On x86, we are using the multiboot specification. I thought that this specification is only available on x86.
In principle, a unikernel is a single application, which runs directly on the hardware/VM. Our ELF loader parse the ELF application to determine the thread local storage. On x86, Qemu loads the unikernel as initrd into the memory. The loader just initialize the system. I miss a similar feature on ARM. Maybe I oversee something. Cheers Stefan > Am 14.04.2023 um 11:03 schrieb Peter Maydell <peter.mayd...@linaro.org>: > > On Fri, 14 Apr 2023 at 08:35, Stefan Lankes > <slan...@eonerc.rwth-aachen.de> wrote: >> Currently, the flag `--initrd` is only support for Linux ARM kernels. >> However, also other ELF kernels could depend on an initial ramdisk. >> This PR loads also the initrd for ELF kernels and announce the >> location by the nodes "/chosen/initrd-start" and >> "/chosen/initrd-end" within the device tree. > > What are these "other ELF kernels" ? Is there some defined > specification of bootloader you're trying to implement here? > > Currently QEMU for Arm supports two things: > (1) I am a Linux kernel, load me like the Linux kernel defines > (2) I'm just a bare-metal image (ELF file or raw) > > Adding support for some third type of loading would need a > pretty solid justification, eg that this is a very common kind > of image to load, that there is a well defined specification, > that it's supported by lots of other bootloaders, etc. > The bootloading code is too complicated already and I am > very reluctant to add more to it. > > thanks > -- PMM
smime.p7s
Description: S/MIME cryptographic signature
