On 05/15/18 19:14, Marvin Häuser wrote: >> -----Original Message----- >> From: Laszlo Ersek <ler...@redhat.com> >> Sent: Tuesday, May 15, 2018 6:12 PM >> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2- >> de...@lists.01.org >> Cc: gso...@gmail.com; ard.biesheu...@linaro.org; ruiyu...@intel.com; >> eric.d...@intel.com; star.z...@intel.com; jordan.l.jus...@intel.com >> Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
>> See "3.3 Globally Defined Variables" and "Table 10. Global Variables" >> in the UEFI-2.7 spec: >> >> [...] The variables with an attribute of NV are nonvolatile. [...] >> >> [...] >> >> Variable Name Attribute Description >> ------------- --------- ----------- >> [...] >> Boot#### NV, BS, RT [...] >> [...] > > I had hoped it was a recommendation, but indeed it seems to be > mandatory. > What's your opinion on this fact I have always accepted it as a fact, and haven't really thought about volatile Boot#### options ever :) > and how do you think the chances are NV could be made optional? I wouldn't like to guess :) >>>> Second, just because a boot option fails, it should not be removed. >>>> For example, a netboot option could fail, or a USB drive might not >>>> be connected (temporarily). I don't think that's grounds enough for >>>> summarily removing a boot option, in shared reference code. >>> >>> Oh, I was just talking about the possibility, because the current >>> code does remove options under certain conditions. >>> However, for USB devices as you have mentioned, I do see this good >>> practice so long as the option is volatile. >>> There is no point in exposing a boot option to a removable device >>> that is not attached if not to prevent unnecessary Flash cycles as >>> far as I can think. >>> Do you happen to have worries about a scenario I did not consider? >> >> Sure; it's a simple scenario: the user might want the system to >> automatically boot off of a USB drive whenever they connect it, >> before powering on or rebooting the system, rather than boot from the >> hard drive. > > Remember that point was made in the context of enumeration. What I was > saying is that boot options created by the enum code, for removable > drives, are fine to be gone (as they are volatile, or proactively > removed when NV) after a reboot. > If a user wants to boot from such an USB device by default, in my > opinion they should manually create a boot option for it. Otherwise, > if I do not misunderstand your point, you are suggesting the firmware > to keep track of every single bootable USB device ever attached. Thanks for the clarification. I see this all as platform policy. It's up to the platform to auto-generate a boot option for a USB drive (either by calling EfiBootManagerRefreshAllBootOption() or by other means). It's also up to the platform to remove preexistent non-volatile options that it deems unnecessary, or wrong. I'm not suggesting that the platform keep track of every single bootable USB device ever attached. The scenario I described was indeed that the user once adds such a boot option manually, and then the system should likely not remove it automatically. I see now that your point was about auto-generated options only. About those, I think that if a platform calls EfiBootManagerRefreshAllBootOption(), then the platform is also responsible for pruning the auto-generated options that are no longer valid. In OVMF we do both the auto-generation and the (quite heavy-handed!) pruning as well. It's mostly very platform-specific code. One example that I can name without needing many details is the RemoveStaleFvFileOptions() function. >> In general I find that library APIs (especially a *set* of library >> APIs) are very hard to design (because we can't see the future). So, >> "organic growth" works better in practice (even if it leads to "less >> well organized" sets of APIs). This is to say that, if you can >> propose a hook and immediately demonstrate that it saves code for, >> and/or simplifies, multiple platforms, then the new API might be >> justified. (Personally, I usually argue for "three call sites" as a >> minimum. Two might be enough if the code extracted is particularly >> baroque, or undergoes frequent changes.) > > The "problem" is that both hooks are not introduced for sharing code > but for giving the platform developer more freedom without forking > off. > Whether such are accepted ends up being entirely the maintainer's > preference, I guess. You could show the maintainer the two implementations side-by-side: what it takes for the platform in question to implement the desired functionality without the hook (if that's possible at all), and with the hook. Double work, yes, but sometimes nothing else enlightens maintainers. (I know this from both the contributor and the maintainer sides.) Thanks, Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
