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

[Pablo Sebastián Greco]

El 22/7/19 a las 12:15, Peter Robinson escribió:
> On Mon, Jul 22, 2019 at 2:36 PM Tom Rini <trini at konsulko.com> wrote:
>> On Sun, Jul 21, 2019 at 10:46:24AM +0100, Peter Robinson wrote:
>>>>>>> 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.
>> OK, we have a problem here.  A better example than DM would be the
>> various work-arounds we have (or carried for ages) to allow using newer
>> U-Boot with various old and broken kernels.  So no, we need to keep this
>> work-around for a long while.  What's the EOL date for any Linux
>> distribution that uses this broken grub?  The first U-Boot release post
>> that EOL date is when we can drop this particular bit of work-around
>> code.
> Well Fedora 31 would be EOL around Nov/Dec 2020, and while I know the
> CentOS team uses the Fedora U-Boot but I believe they boot their
> arm-32 instances with extlinux to date. I can't speak for any of the
> other distros in this regard.
Well, that is true for CentOS7, but for CentOS8 the plan is to boot 
using EFI also.
> Peter
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot


Pablo.