On 05/10/2011 12:13 AM, Alexander Graf wrote: > > On 10.05.2011, at 06:58, Rob Landley wrote: > >> On 05/09/2011 09:11 AM, Alexander Graf wrote: >>>> C) requires more research, because I have to make sure the >>>> entry point is either doing the 16->32 (or 64) bit startup >>>> dance or that it's being launched in the right mode (which the >>>> bios isn't doing), but vmlinux doesn't need to be decompressed >>>> and copied so it's just making sure we're expecting the right >>>> layer of stuff. Which means reading through arch/x86/boot to >>>> see what the vmlinux->bzImage packaging is adding, I suppose. >>> >>> The issue is that this is not how it works on real hardware. >> >> Real hardware doesn't have the -kernel option. On x86 that option >> is currently patching the rdev area after loading the blob into >> DRAM. >> >>> Grub won't just load a vmlinux file and boot it. >> >> The -kernel option doesn't load grub, it loads a _kernel_. -kernel >> is a linux-specific bootloader. It doesn't chainload other >> bootloaders. > > My point is that -kernel is on the same level as grub. It's a > bootloader - just (mostly) implemented in host mode, not guest mode. > I'm not objecting to your idea. Just saying that what you're doing > isn't streamlined in Linux atm, so you might hit barriers that people > didn't expect :).
Oh sure. That's why I haven't posted the patch yet. I read through enough to assemble a very rough todo list (call load_elf(), figure out if the kernel can run from the read-only ROM blob or if I need to copy it to normal DRAM like some targets do, figure out where the structure rdev used to patch lives in the blob the ELF loaded so we can set the right field in it to specify where the command line lives, figure out what we need to add to said command line...) But it's not in the top 5 of my todo list today... >> By the way, I just did "qemu -kernel qemu-img" an the emulated vga >> screen was very colorful. Feeding it qemu-io gave a different >> pattern of vga text mode garbage. It's happily loading an elf file >> _now_, and spinning its little CPU on the resulting garbage... > > IIRC -kernel loads ELF images as raw blobs atm. Just try to implement > it and you'll see what I mean, seriously :). Which is why -kernel needs to fix up the result (if nothing else, to feed it a command line). > Basically, -kernel with an OpenBSD ELF kernel would be different. My lack of caring about OpenBSD cannot be expressed in words. Does the current -kernel option support OpenBSD kernels? If so, I wouldn't be introducing any regressions. > You somehow need to be able to find out the boot protocol. No, I don't. I need to ignore OpenBSD with the force of a thousand DMV agents on break. "Your new thing would continue not to do something the current -kernel option doesn't support". Yes. Yes it would. I don't see how this is considered a valid objection. > Either it's > defined by architecture or by random OS conventions. If you can > somehow make sure that a kernel really is Linux and nothing else, > speaking some random Linux boot protocol with it is just fine! The current -kernel option will happily load a TEXT FILE. The result does not boot, but it makes pretty pictures in the VGA screen. Feeding -kernel an OpenBSD kernel is only slightly less useful than feeding it a text file, and if you want multiboot you know where to find it. (There's code for that in qemu now, it's just not at all interesting to me.) >> Yes, -kernel has to do setup work before starting the kernel. This >> is true now, it remains true if the kernel is in a different file >> format. -kernel is a linux bootloader, which is not the same thing >> as the -bios option. > > I disagree. -kernel is a _kernel_ bootloader. A linux kernel bootloader. It's 100% linux-specific. Always has been. Feel free to provide a counter-example. Show me how to boot an OpenBSD kernel with "qemu-system-x86_64 -kernel". > There's more out there than just Linux :). The current code disagrees with you. This project's been around for a decade and nobody's ever bothered to add BSD support to -kernel, and I won't either. If you'd be more comfortable if the command line option was renamed "-linux", feel free to submit a patch, but you're currently arguing against the existing code, not against the patch I'm writing. Rob