Any input on this?

It seems that the current behavior isn't ideal:

  *   If BootNext is already set when PlatformBootManagerLib APIs are called, a new BootNext value from the PlatformBootManagerLib code will be ignored (because the original value is cached before the APIs have a chance to set it) and then deleted (when the cached value is consumed after the APIs have been called)
  *   If BootNext is not already set, then the current boot will not be affected by the BootNext value that PlatformBootManagerLib API code sets (because there was no value when the value was cached), but the subsequent boot will boot with the BootNext value set by the APIs during the current boot (because not having a cached value skips the deletion of BootNext).

To me this seems inconsistent and confusing.

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Jeshua Smith via groups.io
Sent: Tuesday, January 3, 2023 11:32 AM
To: devel@edk2.groups.io
Cc: Zhichao Gao <zhichao.gao@intel.com>; Ray Ni <ray.ni@intel.com>
Subject: [edk2-devel] How to select boot device for current boot in response to IPMI System Boot Options commands?

External email: Use caution opening links or attachments

Happy New Year!

I'm trying to figure out the proper place to add code to allow the EFI boot code to respond to the IPMI System Boot Options request to boot a device on the current boot. My initial thought was to change BootNext in the PlatformBootManagerLib APIs, but based on the comment https://www.mail-archive.com/edk2-devel@lists.01.org/msg30378.html it looks like that is *intentionally* unsupported. Does anyone know why we want to avoid PlatformBootManagerLib hooks from being able to set BootNext to control what gets booted on the current boot? Is there an intended alternative way to support the IPMI System Boot Options Command request to use a boot device for the current boot?

Thanks,

Jeshua Smith