OvmfPkg: BDS: remove historic (now defunct) boot mode hack

When PI can distinguish the "full config" boot mode from "assume no
changes", then the following BDS logic is correct:

  if BootMode == BOOT_WITH_FULL_CONFIGURATION:
    //
    // connect all devices
    // create & append each default boot option that's missing
    //
    BdsLibConnectAll
    BdsLibEnumerateAllBootOption
  else if BootMode == BOOT_ASSUMING_NO_CONFIGURATION_CHANGES:
    //
    // just stick with current BootOrder and the Boot#### variables
    // referenced by it
    //

In theory, the first branch is intended to run infrequently, and the
"assume no changes" branch should run most of the time.

However, some platforms can't tell these two boot modes apart. The
following substitute had been introduced:

  //
  // Technically, always assume "full config", but the BootMode HOB is
  // actually meaningless wrt. to "full config" or "assume no changes".
  //
  ASSERT (BootMode == BOOT_WITH_FULL_CONFIGURATION);

  //
  // Key off the existence of BootOrder. Try to prepare an in-memory list
  // of boot options, based on BootOrder and the referenced Boot####
  // variables.
  //
  Status = BdsLibBuildOptionFromVar()

  //
  // If that succeeded, we'll treat it as "assume no changes".  If it
  // failed (*only* if it failed), we'll build default boot options,
  // calling it "full config":
  //
  if EFI_ERROR(Status):
    BdsLibConnectAll()
    BdsLibEnumerateAllBootOption(BootOptionList)

What we have now in OVMF is a mixture of the hack, and the behavior that's
theoretically correct for "full config":
- We assert "full config" -- this is OK.
- We call "connect all" and "enumerate all" deliberately -- this is OK
  too. It matches "full config" which we assert.
- However, we also have the hack in place, which had been meant as an
  alternative.

In order to clean this up, we either need to restore the hack to its
original form (ie. comment out the unconditional calls again), or we ought
to remove the hack altogether.

The unconditional "connect all" + "enumerate all" calls are the correct
approach for OVMF, because we want, in fact, to start with "full config".
The QEMU boot order specification and the set of emulated devices might
change "out of band", which excludes "assume no changes".

In other words, removing the hack corresponds to the "real production"
case that the comment hints at.

Because SetBootOrderFromQemu() may change the BootOrder NvVar, we must
preserve the BdsLibBuildOptionFromVar() function call, in order to
refresh the in-memory list with the new boot priorities.
(The last step of BdsLibEnumerateAllBootOption() is such a call too.)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15326 6f19259b-4bc3-4df7-8a09-765794883524

0 files changed, 0 insertions, 0 deletions