Re: Handling large allocations (bypassing mm?)

[Ard Biesheuvel]

On Fri, 16 Dec 2022 at 18:55, Robbie Harwood <rharwood@redhat.com> wrote:
>
> Ard Biesheuvel <ardb@kernel.org> writes:
>
> > As for supporing kernels from 2012: I don't see why upstream GRUB
> > should care about that. If your distro fork supports those today, you
> > will simply need to carry those patches out of tree a bit longer.
>
> No, it's not a question of distros supporting themselves like this.  For
> better or worse, people expect to be able to install many OSs on their
> drive and have any grub be able to boot any of them.
>
> One such use case I've seen is hardware testing: someone will install
> all the operating systems they care about on a drive, then plug it in to
> the machine with the hardware and try all of them in sequence.  And of
> course there're always hobbyists who just think it's fun to do things
> like that - they file bugs too :)
>
> In any case, it's not a little bit of time we're talking about here -
> even though RHEL 6 is only guaranteed into 2024 right now, RHEL 8 is
> slated to be here until at least 2031.  (Source:
> https://access.redhat.com/support/policy/updates/errata/ )
>

Fair enough.

So are you saying that all downstream GRUBs are mutually compatible,
and can boot other distro kernel images, and it is simply mainline
GRUB that needs to be modified to incorporate those existing
out-of-tree changes?

My stake in this is mainly from the opposite side, i.e., avoiding
pointless per-arch deviations when doing EFI boot from any bootloader.
Upstreaming the EFI handover protocol and other x86 quirks into GRUB
while we already have all the pieces we need to make EFI boot almost
entirely arch-agnostic seems like a mistake to me. And given that the
x86 EFI handover protocol is not in mainline GRUB at the moment, I
wonder how this all fits with your (plural) assertion that older
kernels must be supported by mainline GRUB, as it doesn't support any
of those today.