From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1YbUxH-0006DX-7w for mharc-grub-devel@gnu.org; Fri, 27 Mar 2015 10:09:47 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbUxB-000677-Gg for grub-devel@gnu.org; Fri, 27 Mar 2015 10:09:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbUx7-0005AJ-CR for grub-devel@gnu.org; Fri, 27 Mar 2015 10:09:41 -0400 Received: from mail.csclub.uwaterloo.ca ([129.97.134.52]:54445) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbUx7-0005A3-91 for grub-devel@gnu.org; Fri, 27 Mar 2015 10:09:37 -0400 Received: from caffeine.csclub.uwaterloo.ca (caffeine.csclub.uwaterloo.ca [129.97.134.17]) by mail.csclub.uwaterloo.ca (Postfix) with SMTP id 564802063E; Fri, 27 Mar 2015 10:09:35 -0400 (EDT) Received: by caffeine.csclub.uwaterloo.ca (sSMTP sendmail emulation); Fri, 27 Mar 2015 10:09:35 -0400 From: "Lennart Sorensen" Date: Fri, 27 Mar 2015 10:09:35 -0400 To: The development of GNU GRUB Subject: Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader Message-ID: <20150327140935.GC29558@csclub.uwaterloo.ca> References: <1422640462-28103-1-git-send-email-daniel.kiper@oracle.com> <1422640462-28103-6-git-send-email-daniel.kiper@oracle.com> <54E76C2F0200007800062262@mail.emea.novell.com> <20150327133228.GN8294@olila.local.net-space.pl> <55156C7E020000780006E98E@mail.emea.novell.com> <551560E8.5020306@citrix.com> <55157176020000780006E9F9@mail.emea.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55157176020000780006E9F9@mail.emea.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 129.97.134.52 Cc: Juergen Gross , keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, Andrew Cooper , Daniel Kiper , roy.franz@linaro.org, ning.sun@intel.com, david.vrabel@citrix.com, phcoder@gmail.com, xen-devel@lists.xenproject.org, qiaowei.ren@intel.com, richard.l.maliszewski@intel.com, gang.wei@intel.com, fu.wei@linaro.org X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 14:09:45 -0000 On Fri, Mar 27, 2015 at 02:04:22PM +0000, Jan Beulich wrote: > >>> On 27.03.15 at 14:53, wrote: > > On 27/03/15 13:43, Jan Beulich wrote: > >>>>> On 27.03.15 at 14:32, wrote: > >>> On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote: > >>>>>>> On 30.01.15 at 18:54, wrote: > >>>>> We need more fine grained knowledge about EFI environment and check > >>>>> for EFI platform and EFI loader separately to properly support > >>>>> multiboot2 protocol. > >>>> ... because of ... (i.e. I can't see from the description what the > >>>> separation is good for). Looking at the comments you placed > >>>> aside the variables doesn't help me either. > >>>> > >>>>> In general Xen loaded by this protocol uses > >>>>> memory mappings and loaded modules in simliar way to Xen loaded > >>>>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform > >>>>> and efi_loader. > >>>> And if I'm guessing things right, then introducing efi_loader but > >>>> leaving efi_enabled alone (only converting where needed) would > >>> efi_enabled is not fortunate name for new usage. Currently it means > >>> that Xen binary have or does not have EFI support build in. However, > >>> if we build in multiboot2 protocol into xen.gz then it means that > >>> it can ran on legacy BIOS or EFI platform. So, I think that we > >>> should rename efi_enabled to efi_platform because it will mean > >>> that Xen runs on EFI platform or not. > >> I disagree here. > >> > >>> efi_loader is used to differentiate between EFI native loader > >>> and multiboot2 protocol. > >> And I agree here. > > > > I suppose "built with efi support" is known because of CONFIG_EFI or > > not, and doesn't need a variable. > > > > However, "booted legacy" vs "booted EFI" does need distinguishing at > > runtime, as either is possible. > > Right, but that's what efi_enabled is supposed to express after > the change; there's no need to express "built with EFI support". > It just so happens that right now, without all these changes, > built-with-EFI-support == runs-on-EFI. Then how about 'efi_booted' as the variable name. -- Len Sorensen