All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robbie Harwood <rharwood@redhat.com>
To: Glenn Washburn <development@efficientek.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Cc: The development of GNU GRUB <grub-devel@gnu.org>,
	Daniel Kiper <dkiper@net-space.pl>
Subject: Re: [PATCH] grub-shell: Add flexibility in QEMU firmware handling
Date: Tue, 24 Jan 2023 16:21:34 -0500	[thread overview]
Message-ID: <jlgr0vjtyqp.fsf@redhat.com> (raw)
In-Reply-To: <20230123140947.7998a115@crass-HP-ZBook-15-G2>

[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]

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.

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.

Be well,
--Robbie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

  parent reply	other threads:[~2023-01-24 21:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-21  6:15 [PATCH] grub-shell: Add flexibility in QEMU firmware handling Glenn Washburn
2023-01-23  9:28 ` Gerd Hoffmann
2023-01-23 20:09   ` Glenn Washburn
2023-01-24  8:16     ` Gerd Hoffmann
2023-01-26  5:23       ` Glenn Washburn
2023-01-24 21:21     ` Robbie Harwood [this message]
2023-01-26  4:53       ` Glenn Washburn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jlgr0vjtyqp.fsf@redhat.com \
    --to=rharwood@redhat.com \
    --cc=development@efficientek.com \
    --cc=dkiper@net-space.pl \
    --cc=grub-devel@gnu.org \
    --cc=kraxel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.