From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Kiper Subject: Re: New Xen boot infrastructure proposal Date: Wed, 22 May 2013 17:01:04 +0200 Message-ID: <20130522150104.GE25607@debian70-amd64.local.net-space.pl> References: <363082f7-72f9-41cc-a5b4-75ce235e6493@default> <519B7EC402000078000D7B3C@nat28.tlf.novell.com> <20130522140948.GA25607@debian70-amd64.local.net-space.pl> <519CF35902000078000D8264@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <519CF35902000078000D8264@nat28.tlf.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: xen-devel , keir@xen.org, ian.campbell@citrix.com, konrad.wilk@oracle.com, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On Wed, May 22, 2013 at 03:33:29PM +0100, Jan Beulich wrote: > >>> On 22.05.13 at 16:09, Daniel Kiper wrote: [...] > > I think that passing info about system via many not "linked" variables > > is not the best idea. It works in that way today because multiboot > > structure is not extensible. That is why I think we should find new > > solution. Our new custom build structure which contains only stuff > > required by Xen looks good. All members are easliy accessible from C. > > It could be easliy extended (if we need it just add new member) because > > it would not be linked with specific boot protocol. > > Why does it matter whether the MBI structure is extensible? If we stick to current MBI I am not able to pass (in sensible way), from preloader to __start_xen(), e.g. ACPI and EFI stuff from multiboot2 protocol. That is why I think we should build our own struct which is not linked with any boot protocol. That way we could avoid similar problems in the future. > Rather than copying everything around a number of times, we > can as well use is where it lives naturally. The only requirement This is the best approach if we would have one type of boot protocol. It is not true if we would like to support more then one. > is that all information be accessible - whether in one strcture, > two, or a dozen doesn't matter. I agree that this is not a must but I prefer to have "all in one" :-)))... We could do that cleanups (by the way) if we decide what to do with above issues. Daniel