From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1YbV8y-0007Ma-H9 for mharc-grub-devel@gnu.org; Fri, 27 Mar 2015 10:21:52 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbV8w-0007KY-Ik for grub-devel@gnu.org; Fri, 27 Mar 2015 10:21:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbV8t-0002I2-9o for grub-devel@gnu.org; Fri, 27 Mar 2015 10:21:50 -0400 Received: from mail.csclub.uwaterloo.ca ([129.97.134.52]:38933) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbV8t-0002Hu-44 for grub-devel@gnu.org; Fri, 27 Mar 2015 10:21:47 -0400 Received: from caffeine.csclub.uwaterloo.ca (caffeine.csclub.uwaterloo.ca [129.97.134.17]) by mail.csclub.uwaterloo.ca (Postfix) with SMTP id 8E9A22080B; Fri, 27 Mar 2015 10:21:45 -0400 (EDT) Received: by caffeine.csclub.uwaterloo.ca (sSMTP sendmail emulation); Fri, 27 Mar 2015 10:21:45 -0400 From: "Lennart Sorensen" Date: Fri, 27 Mar 2015 10:21:45 -0400 To: The development of GNU GRUB Subject: Re: [Xen-devel] [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader Message-ID: <20150327142145.GD29558@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> <20150327140935.GC29558@csclub.uwaterloo.ca> <55157510020000780006EA56@mail.emea.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55157510020000780006EA56@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:21:51 -0000 On Fri, Mar 27, 2015 at 02:19:44PM +0000, Jan Beulich wrote: > >>> On 27.03.15 at 15:09, wrote: > > 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. > > Why should we rename a variable that's perfectly suitable for the > purposes we have? Even more so that we don't just want to > express that we were booted from EFI, but also that we're running > in a respective environment, including using tables coming from > EFI and using runtime services (unless specifically disabled). If > anything we could follow Linux and make efi_enabled a bit mask. OK, so it isn't just to tell that you booted from EFI. -- Len Sorensen