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

[Tom Rini]

On Mon, Jul 22, 2019 at 09:07:40PM +0200, Heinrich Schuchardt wrote:
> On 7/22/19 9:02 PM, Tom Rini wrote:
> >On Mon, Jul 22, 2019 at 08:51:41PM +0200, Heinrich Schuchardt wrote:
> >>On 7/22/19 3:36 PM, Tom Rini 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.
> >>
> >>The current behavior contradicts the UEFI spec. Our target is to
> >>implement a UEFI compliant firmware.
> >
> >Our target is to be both compliant and functional, and functional wins.
> >
> >>If OpenBSD does not change their broken boot loader will we never
> >>correct U-Boot? That would not make sense to me.
> >
> >I'm sorry, I don't see the connection.  It's not "GRUB won't change to
> >be compliant" it's "GRUB changed things but it's going to take a long
> >while for that to be deployed out".
> >
> >>Old distros tend not to to update their U-Boot release. E.g. Debian
> >>Stretch is still on U-Boot v2016.11. So why would you care about its EOL?
> >
> >Because I want to make it really hard for people to end up in a "does
> >not boot now" mode.
> >
> >>I could agree if you suggested that we should re-enable the workaround
> >>until the major distros use a compatible GRUB in their stable release
> >>like Debian Buster does.
> >>
> >>Let's be proactive and analyze if anything is missing in Fedora Rawhide
> >>GRUB. If yes, we should contact the maintainer and clarify which
> >>adjustments are possible until the Fedora 31 release.
> >
> >I don't want it to be "just latest stable has it".  I want it to be
> >"supported releases have it".
> 
> RHEL distros are supported for 10 years. Are you serious?

RHEL doesn't support 32bit ARM, which is the problem code path in
question, so we're good there.  Otherwise, depending on the overhead of
maintaining a work-around, yes.  We kept one around for sunxi until it
was very clear that yes, really, there was no one around using that
particular kernel anymore.  And people do expect to be able to throw
new hardware at old distros and U-Boot falls on the "needs to work with
the old SW" side of the line and GRUB falls on the "it's the distro, use
what's there" side.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190722/3ecb69c7/attachment.sig>