Re: [edk2-devel] [PATCH 0/5] ArmPkg/PlatformBootManagerLib: play nice without ConnectAll()

["Leif Lindholm" <leif@nuviainc.com>]

On Wed, May 27, 2020 at 12:50:53 +0200, Ard Biesheuvel wrote:
> > > > Not attempting a fallback boot onto network is probably an acceptable
> > > > change to pick up, but having an undocumented hotkey as the only way
> > > > into a shell that now doesn't map devices could be a bit aggravating.
> > > > 
> > > 
> > > It is not the only way, and it is not even the preferred way. Patch 5/5 adds
> > > an option to the UiApp root menu to enter the UEFI Shell, in a way that is
> > > independent from boot option handling. Since you enter UiApp first, all
> > > handles will be connected and boot options refreshed as usual.
> > > 
> > > In cases where you want to avoid this from happening, you can use the 's'
> > > key to drop into a shell directly.
> > 
> > Yes, that's exactly what I am referring to. But in order for the new
> > (and I agree improved) functionality to be available, the new Shell
> > library needs to be explicitly added to .dsc for the platforms affected.
> > 
> > I want an active decision to be made about how that is going to
> > happen, if it is going to happen, as part of the conversation about
> > *this* set. Merging this and *then* looking into it makes for too
> > harsh a break in behaviour.
> > 
> 
> All existing platforms that incorporate ArmPkg's PlatformBootManagerLib must
> add this NULL library class resolution to UiApp first. So once we agree that
> this approach is acceptable (including the change to ShellPkg), I can
> prepare a patch for edk2-platforms implementing this for all such platforms
> living there. I suggest that we don't do the 3-way handshake here (edk2 pre,
> edk2-platforms, edk2 post), given that the build won't break, it's just that
> if you pull and build your platform right at the minute between merging the
> edk2 changes and the edk2-platform ones, you will see the slightly
> unintuitive behavior if you also happen to clear your Boot#### variables at
> the same time.

Yeah, that's fine with me.
But I'd prefer that set to be ready to go immediately afer this one
hits.

(Insert generic note on benefit of *not* breaking the project up into
ever increasing number of repositories.)

Should I interpret this set more as RFC (in which case I may have
slightly overreacted) than the PATCH it says in the subject line?

/
    Leif