All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] x86/EFI: define and use EFI_DIR make variable, defaulting to /usr/lib64/efi
Date: Tue, 24 Jul 2012 02:39:18 -0700	[thread overview]
Message-ID: <20120724093918.GA8228@US-SEA-R8XVZTX> (raw)
In-Reply-To: <1343120277.5797.101.camel@zakaz.uk.xensource.com>

On Tue, Jul 24, 2012 at 01:57:57AM -0700, Ian Campbell wrote:
> On Mon, 2012-07-23 at 11:03 +0100, Jan Beulich wrote:
> > > I noticed that (at least on Debian) grub uses /usr/lib/grub/<arch>-efi
> > > and elilo uses /usr/lib/elilo.
> > 
> > It's definitely /usr/lib64/efi/elilo.efi on SLE11, so I'm afraid this
> > really ins't well standardized (and hence an EFI_DIR override is
> > warranted, yet settling on a proper default may be problematic).
> > 
> > > Does that mean we should be using /usr/lib/xen/efi rather than /usr/lib/efi?
> > > 
> > > What is the policy for EFI install location on RPM/LSB based systems?
> > 
> > Don't know.
> > 
> > >> > We already have EFI_MOUNTPOINT under xen/*, I think EFI_DIR under there
> > >> > (or in config/*) is fine also.
> > >> 
> > >> That part wasn't controversial (if generally useful), but imo it
> > >> shouldn't expand to an open-coded path (unless put into
> > >> config/x86_64.mk).
> > > 
> > > I could live with that. Unlike LIBDIR, where getting it wrong can mean
> > > things don't work, getting EFI_DIR wrong is merely ugly.
> > 
> > Not exactly - it might still mean that boot loader installation (and
> > update) doesn't work anymore. But getting things consistent
> > would be a one-time per-distro task, so ought to be manageable.
> 
> So is the upshot that the original patch is basically OK, subject to
> settling on a reasonable default for EFI_DIR? With the proviso that
> there's basically no standardisation of this stuff and every distro
> seems to be choosing a different path?

My Apologies for a late reply - I've been traveling over the past few
days.

That was my conclusion as well. For one more data point, it seems that
the GRUB2 efi binaries are deployed directly to
/boot/efi/EFI/redhat/grub.efi on Fedora/RHEL systems.

> /usr/lib64/efi seems as good as anything. Suitable alternatives might
> be /usr/{lib,lib64}/xen/efi/...

I think that /boot/xen.efi could also be suitable, but it is farther
from the pattern that we see in elilo and GRUB2 EFI binary locations
on SUSE and Debian systems. But I figure that /usr/lib64/efi is as
good as any other default choice.

Matt

  reply	other threads:[~2012-07-24  9:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-16 23:50 [PATCH] x86/EFI: define and use EFI_DIR make variable, defaulting to /usr/lib64/efi Matt Wilson
2012-07-20 18:52 ` Matt Wilson
2012-07-23  7:49 ` Jan Beulich
2012-07-23  8:05   ` Olaf Hering
2012-07-23  8:20     ` Jan Beulich
2012-07-23  8:36       ` Olaf Hering
2012-07-23  8:58         ` Jan Beulich
2012-07-23  8:43       ` Ian Campbell
2012-07-23  9:07         ` Jan Beulich
2012-07-23  9:35           ` Ian Campbell
2012-07-23 10:03             ` Jan Beulich
2012-07-23 10:25               ` Ian Campbell
2012-07-23 10:28                 ` Jan Beulich
2012-07-24  8:57               ` Ian Campbell
2012-07-24  9:39                 ` Matt Wilson [this message]
2012-07-24 10:40                   ` Jan Beulich
2012-07-24  9:40                 ` Jan Beulich
2012-07-24 10:11                   ` Ian Campbell
2012-07-24 10:43                     ` Jan Beulich
2012-07-24 12:04                       ` Matt Wilson
2012-07-24 12:28                         ` Jan Beulich
2012-07-24 12:38                           ` Ian Campbell
2012-07-24 12:53                             ` Jan Beulich
2012-07-24 13:51                           ` [PATCH v2] " Matt Wilson

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=20120724093918.GA8228@US-SEA-R8XVZTX \
    --to=msw@amazon.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=olaf@aepfle.de \
    --cc=xen-devel@lists.xen.org \
    /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.