Re: [PATCH] grub-shell: Add flexibility in QEMU firmware handling

[Glenn Washburn]

On Tue, 24 Jan 2023 16:21:34 -0500
Robbie Harwood <rharwood@redhat.com> wrote:

> Glenn Washburn <development@efficientek.com> writes:
> 
> > On Mon, 23 Jan 2023 10:28:09 +0100
> > Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> >> On Sat, Jan 21, 2023 at 12:15:20AM -0600, Glenn Washburn wrote:
> >> > The current qemu firmware paths for arm-efi and arm64-efi are not
> >> > available on Ubuntu/Debian but are hardcoded. Switch to first
> >> > looking for firmware files in the source directory and if not
> >> > found, look for them in locations where Debian installs them.
> >> 
> >> I'd suggest to inspect the *.json files in
> >> /usr/share/qemu/firmware/ to find distro-installed firmware files.
> >
> > Yes, I know about this, but decided against it so as not to do real
> > or hacked up json parsing and add another dependency (eg. jq). I
> > think right now the unstated GRUB policy is that these tests are
> > only officially supported to run on (newer) debian systems, so I
> > felt that hard coding was reasonable. It occurs to me that its
> > possible (though I suspect very improbable), that Redhat based
> > distros run the tests when building the official RPM. Is there a
> > reason that redhat would be very interested in the change you're
> > suggesting?
> 
> We don't run the tests during builds.  That has more to do with
> buildtimes and historical considerations than the tests themselves.

I don't understand the last sentence, but I'm gathering that you guys
don't ever run these tests.

> Personally, I would write this in such a way that we could, e.g.,
> check the debian locations, and fallback to the fedora locations if
> they don't exist, and so forth for other distros.  That said, grub
> has not been in favor of handling compatibility in this way in the
> past and seems to prefer pushing that burden onto the distros and
> their users.

Yeah, I guess I don't personally care enough, even if its trivial. Is
the point that it would make it easier for someone (not me) to send a
patch adding Redhat support? If so, then they could add what your
proposing in that patch. If other distros want to patch their source so
that users getting the source ball can run the tests without having to
manually change the paths, this current implementation makes that easy,
just change the paths in a patch. I'm not completely opposed to the
idea if someone else wants to do it, but I'm not personally interested
in making it uglier and more complex than it already is. Despite this,
I appreciate your input.

Glenn