On Tue, 18 Feb 2025 at 21:23, Keith Packard via <qemu-devel@nongnu.org> wrote: > > The existing loader supports raw binary blobs with the entry point > defined as the start of the blob. Add support for loading ELF files by > first checking if the provided filename has a valid ELF header, > falling back to the existing loader code when that fails. > > Signed-off-by: Keith Packard <kei...@keithp.com>
Ths code does what it intends to, and I'm not saying we should definitely *not* have it. I do think it's worth considering whether we need it, given that you can already load an ELF image via the generic loader (-device loader). -kernel is a very "do what I mean" option that differs from target to target, but what it's ideally supposed to mean is "this is a Linux kernel, boot it like a Linux kernel". Some of our targets also overload it to additionally have the behaviour "but if it's an ELF file, load it as an ELF file, not like a kernel" (notably at least arm M-profile). But I think that's something I'd consider a mistake in retrospect, which we can't change now for backwards compatibility reasons. (In particular it means we can't have "-kernel kernel.elf" mean "this is a Linux kernel which is an ELF file and it wants all the usual CPU setup that Linux's booting requirements mandate".) So for target/rx, I guess what I'm saying is that if Linux kernels for this architecture really are usually floating around as ELF files then we should support that, but if this is just "some users would like a way to load an ELF file, start at the ELF entry point, and do no other setup of the CPU or system before running code" then it might be better to instead point those users at the generic loader (which does exactly that job and does the same thing on all target architectures), rather than adding a second mechanism for doing that. thanks -- PMM
