From mboxrd@z Thu Jan 1 00:00:00 1970 From: konrad wilk Subject: Re: [PATCH for-xen-4.5 v4 00/18] xen: Break multiboot (v1) dependency and add multiboot2 support Date: Thu, 23 Oct 2014 13:55:57 -0400 Message-ID: <5449412D.40405@oracle.com> References: <1413555132-22138-1-git-send-email-daniel.kiper@oracle.com> <544146FE020000780003FA95@mail.emea.novell.com> <20141017154936.GE3467@olila.local.net-space.pl> <5448F24D02000078000415FE@mail.emea.novell.com> <5448E1B0.6050301@citrix.com> <20141023145745.GP3467@olila.local.net-space.pl> <54493A3E0200007800041881@mail.emea.novell.com> <20141023155020.GQ3467@olila.local.net-space.pl> <5449434502000078000418B9@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XhMcY-0003Vz-EN for xen-devel@lists.xenproject.org; Thu, 23 Oct 2014 17:56:22 +0000 In-Reply-To: <5449434502000078000418B9@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich 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, ross.philipson@citrix.com, xen-devel@lists.xenproject.org, qiaowei.ren@intel.com, richard.l.maliszewski@intel.com, gang.wei@intel.com, fu.wei@linaro.org List-Id: xen-devel@lists.xenproject.org On 10/23/2014 12:04 PM, Jan Beulich wrote: >>>> On 23.10.14 at 17:50, wrote: >> OK, AIUI you suggest that I should parse all multiboot2 data in reloc.c >> and put all things in multiboot1 struct which lives on trampoline. Then >> I should add global variables for EFI_HANDLE and EFI_SYSTEM_TABLE somewhere >> in x86_64.S and initialize them from reloc.c. After that I should call >> efi_start() immediately after reloc() if Xen runs on EFI platform. > > I wouldn't call this "parse", but beyond that it sounds roughly right. > Whether you need global variables or can find some other > mechanism to propagate the EFI specific things is secondary. This seems to lead to more spaghetti code - why not make it a more nice mechanism right away? Is that because you want to have this in a separate "bin" in case it has bugs and won't influence the rest of the code? And then later if it all works then integrate and cleanup? Or skip that altogether? > > Jan >