Hi Jeremy, [...] > >>> > >>> Back when we added this we intentionally left loading an initramfs > >>> loaded via the command line out. > >>> We wanted people to start using the LoadFile2 protocol instead of the > >>> command line option, which suffered from various issues -- e.g could > >>> only be loaded if it resided in the same filesystem as the kernel and > >>> the bootloader had to reason about the kernel memory layout. > >>> I don't think measuring the command line option as well is going to > >>> cause any problems, but isn't it a step backward? > >> > >> Thanks for looking at this. Since no one else seems to have commented, I > >> will just express IMHO, that both methods are useful in differing > >> circumstances. > >> > >> For a heavyweight Linux aware bootloader like grub/sd-boot the > >> INITRD_MEDIA_GUID is obviously preferred. But, for booting strictly out > >> out of a pure UEFI environment or Linux unaware bootloader (ex: UEFI > >> shell), > > > > I am not sure I am following on the EfiShell. It has to run from an > > EFI firmware somehow. The two open-source options I am aware of are > > U-Boot and EDK2. > > U-Boot has full support for the LoadFile2 protocol (and the > > INITRD_MEDIA_GUID). In fact, you can add the initramfs/dtb/kernel > > triplets as your boot options, supported by the EfiBoot manager and > > you don't need grub/systemd boot etc. > > > > I don't think you can do that from EDK2 -- encode the initrd in a boot > > option, but you can configure the initramfs to be loaded via LoadFile2 > > in OMVF via the 'initrd' shell command. > > Oh, I guess the shell is a bad example because I was unaware that there > was a initrd option in it now. I'm buying into the boot loader/boot > manager distinction, where the manager is largely unaware of the target > OS's specific needs (in this case, having the initrd GUID set). Yes, FWIW what was added in U-Boot needs to be aware of the Linux-specific GUID, but as far as the EFI BootOptions defined in the Boot manager, we aren't violating anything in the EFI spec. On the contrary, we use the _EFI_LOAD_OPTION exactly as the spec describes. > > > > > >> the commandline based initrd loader is a useful function. > >> Because, the kernel stub should continue to serve as a complete, if > >> minimal implementation for booting Linux out of a pure UEFI environment > >> without additional support infrastructure (shim/grub/etc). So, it seems > >> that unless there is a reason for divergent behavior it shouldn't exist. > >> And at the moment, the two primary linux bootloaders grub2 and sdboot > >> are both using the INITRD_MEDIA_GUID. Given the battering ram has been > >> successful, it isn't a step backward. > > > > I am not saying we shouldn't. As I said I don't think this patch > > breaks anything. I am just wondering if enhancing EDK2 to load the > > initramfs via LoadFile2 for more than OVMF is a better option. > > There is a separation of concerns argument here. People regularly > complain about firmware implementations tuned for windows, but making > the FW aware of this GUID is doing the same thing for Linux. > So, IMHO > that should be avoided, rather assuring the firmware is made as OS > agnostic as possible, and the OS specifics are moved into the OS boot > loader, one of which is this stub. It would make more logical sense to > have the stub set the GUID from built in command line defaults. To be > clear, i'm not suggesting that. I get the separation point but .... If you do it the other way around you *force* people to use specific OS loaders that implement OS-specific protocols. And the EFI stub is not the problem here nor are distros that use such loaders. However, vertical distros for embedded boards which don't need all the added complexity have a reasonable way out. Anyway, since Ard doesn't plan to deprecate initrd=, the patch is reasonable, I have no objections Thanks /Ilias > > > >
