> >>> On Fri, Jul 19, 2019 at 7:28 PM Heinrich Schuchardt <[email protected]> > >>> 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 _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
