From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH for-xen-4.5 v4 00/18] xen: Break multiboot (v1) dependency and add multiboot2 support Date: Thu, 23 Oct 2014 12:08:32 +0100 Message-ID: <5448E1B0.6050301@citrix.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XhGFz-0001sH-J0 for xen-devel@lists.xenproject.org; Thu, 23 Oct 2014 11:08:39 +0000 In-Reply-To: <5448F24D02000078000415FE@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 , Daniel Kiper Cc: Juergen Gross , keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, 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 23/10/14 11:19, Jan Beulich wrote: >>>> On 17.10.14 at 17:49, wrote: >> What is your main concern here (beside that it is big patch series)? > The size alone is not the reason. As already said, I'm not convinced > that the approach you use is ultimately the right one (and Andrew > seems to agree, at least to some degree). And then, looking at your > track record, apart from some kexec (and even older tool stack) > work there hasn't been much you've been doing earlier particularly > with the kind of fragile initial boot code. Hence I think the only > viable route for you to get MB2 code merged is to just add it > _without_ largely re-writing all sorts of other code. Once that > happened we can then go and see whether the consolidation you're > thinking of is (a) the right approach and (b) you're the one to carry > it out. > > Jan > To add to this a little. I still can't see a reasonable justification for the new "multiboot data" type. I think it would be perfectly reasonable keep the multiboot1/2 distinction up until the boot_info stage, and cast the pointer based on multiboot magic. This would vastly reduce the changes in the boot assembly. ~Andrew