[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/EFI: define and use EFI_DIR make variable, defaulting to /usr/lib64/efi



On Tue, 2012-07-24 at 13:28 +0100, Jan Beulich wrote:
> >>> On 24.07.12 at 14:04, Matt Wilson <msw@xxxxxxxxxx> wrote:
> > On Tue, Jul 24, 2012 at 03:43:01AM -0700, Jan Beulich wrote:
> >> >>> On 24.07.12 at 12:11, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> >> > On Tue, 2012-07-24 at 10:40 +0100, Jan Beulich wrote:
> >> >> >>> On 24.07.12 at 10:57, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 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?
> >> >> 
> >> >> Yes, that's my understanding too.
> >> >> 
> >> >> > /usr/lib64/efi seems as good as anything. Suitable alternatives might
> >> >> > be /usr/{lib,lib64}/xen/efi/...
> >> >> 
> >> >> Until we know better, I'd prefer to continue to use the location
> >> >> we used so far (i.e. /usr/lib64/efi).
> >> > 
> >> > OK by me.
> >> > 
> >> > Are you going to ack / commit this patch?
> >> 
> >> Once we see a version matching the outcome of the discussion
> >> I would, certainly. Adjusting the patch that was sent earlier
> >> would be something I'd likely get to only later this or next week.
> > 
> > The current patch places xen.efi in /usr/lib64/efi/
> > 
> > $ find dist -name *efi
> > dist/install/usr/lib64/efi
> > dist/install/usr/lib64/efi/xen-4.2.efi
> > dist/install/usr/lib64/efi/xen-4.efi
> > dist/install/usr/lib64/efi/xen-4.2-unstable.efi
> > dist/install/usr/lib64/efi/xen.efi
> > 
> > Is there some other change needed?
> 
> The placement of the default EFI_DIR definition needs adjustment
> iirc - if we're going to hard-code an architecture specific directory,
> that definition ought to live in config/x86_64.mk.

With an alternative in config/x86_32.mk? 

Or do these belong in StdGNU.mk etc?



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.