On 02/06/20 19:26, Heinrich Schuchardt wrote: > On 2/6/20 3:03 PM, Ard Biesheuvel wrote: >> + status = efi_bs_call(handle_protocol, handle, &lf2_proto_guid, >> + (void **)&lf2); >> + if (status != EFI_SUCCESS) >> + return status; > > You require here that there is a handle exposing the device path > protocol with the initrd specific device path. On the same handle the > EFI_LOAD_FILE2_PROTOCOL must be installed which will load the initrd > file when called with the same device path. > > An alternative implementation would simple loop over all instances of > the EFI_LOAD_FILE2_PROTOCOL and try to load the initrd. That's not a great idea IMO. EFI_LOAD_FILE2_PROTOCOL instances take device-specific filenames / pathnames to load. If you pass any particular pathname (e.g. "initrd" or "\\initrd") to random EFI_LOAD_FILE2_PROTOCOL instance in the protocol database, there could be undesired results / side effects. (It could cause network activity, for example.) Sticking with a VenMedia (i.e. GUID-ed) devpath is much safer; it practically lets us define our own device-specific filename / pathname space. (And in my other email, I suggested "use an empty devpath" for device-specific pathname, because that's the simplest, it looks spec-conformat, and it's safe, because our GUID makes the load attempt unique already.) I do agree with your question though: "Please, indicate which software you expect to expose the initrd related EFI_LOAD_FILE2_PROTOCOL." Thanks Laszlo
