[U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()

[Peter Robinson]

> >>> On Fri, Jul 19, 2019 at 7:28 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >>>>
> >>>> In GRUB before 2.04 a bug existed which did not allow booting some ARM32
> >>>> boards if U-Boot did not disable caches, cf.
> >>>> https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html
> >>>>
> >>>> In ExitBootServices() we were disabling the caches by calling
> >>>> cleanup_before_linux(). This workaround is not needed anymore.
> >>>
> >>> Do we want to remove this straight away? A lot of distributions will
> >>> take time to move to grub 2.04 because it's been a long time between
> >>> grub releases so they'll have quite a patch delta to re-align to the
> >>> new release. Fedora for example will rebase to grub 2.04 in Fedora 32
> >>> which will start development end of August but won't be released until
> >>> next year.
> >>
> >> As described below this code does not remove any functionality that was
> >> active in U-Boot v2019.04 or v2019.07.
> >>
> >> I can see nothing in https://fedoraproject.org/wiki/Updates_Policy
> >> stopping GRUB 2.04 from being made available for stable Fedora releases.
> >
> > The maintainers believe that it's too intrusive to land now and they
> > want maximum testing time before it gets to stable users, funnily
> > enough people don't like it when their machines cease to boot.
>
> Why should anybody's machines cease to boot?
>
> If Fedora does not role out a new U-Boot they are fine. If Fedora roles
> out a new U-Boot they should role out a matching GRUB and they are fine too.
>
> The venturous who build their own U-Boot should know how to role back
> their system if needed.

You've clearly never maintained a distribution across 1000s of device
types and 100s of thousands of users.

We will be shipping Fedora 31 with U-Boot 2019.10 and the current
version of grub that the maintainers wish to support, if that requires
me to revert a number of your changes I will, which will be an
inconvenience and probably take more time than I have spare but I will
survive. I find it strange you fix one OS only to break another. How
will this work for users that want to boot a newly released device
which has recently added U-Boot support to an already released stable
OS?

If you wish to actively break currently working use cases that's your
prerogative that is your choice but I find breaking currently working
use cases without a reasonable window to migrate dependencies actively
hostile which has tended to not be the way U-Boot has worked in the
past for such things as DM, so breaking a interface to the way OSes
boot IMO is even worse.

Peter