From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: New Xen boot infrastructure proposal Date: Wed, 22 May 2013 17:40:15 +0100 Message-ID: References: <20130522155916.GG25607@debian70-amd64.local.net-space.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130522155916.GG25607@debian70-amd64.local.net-space.pl> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel Kiper , Jan Beulich Cc: xen-devel@lists.xensource.com, keir@xen.org, ian.campbell@citrix.com, Konrad Rzeszutek Wilk , stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 22/05/2013 16:59, "Daniel Kiper" wrote: > On Wed, May 22, 2013 at 04:10:17PM +0100, Jan Beulich wrote: >>>>> On 22.05.13 at 16:43, Daniel Kiper wrote: >>> For example it will be very difficult to >>> pass (in sensible way), from preloader to Xen, info about ACPI and EFI >>> stuff. >> >> Why do you think this is going to be "very difficult"? It's a list of >> elements (very much like the enumerated concept I had thought >> of [without having looked at grub2 yet at that point; now I have] >> and that you had asked back about. All we'd need to do is iterate >> over the array of blocks and stash away the information we care >> about (into existing variables where possible, and into newly >> created ones otherwise). > > I though more about taste (that is why I added remark: in sensible way) > than about implementation which is of course quiet simple. We could > solve the problem of passing info for which place does not exists > in MBI at least in three ways: > - create next global variable which is awful for me (or use > if it exists but is awful too), > - pass this multiboot2 stuff almost directly (in real it must > be copied to safe place; in multiboot protocol case required > stuff is copied to trampoline); you mentioned about that in > other email; better but not nice for me, > - preloader should extract all needed stuff from structures > passed by multiboot or multiboot2 protocol and put it in > boot protocol independent struct which is then passed to > __start_xen(); best for me; I described why in other emails. This third option is fine by me, but it is just a big struct to be passed to Xen. The extensible self-describing list format, and architecture independence, don't really add value that I can see. If I were implementing this, I'd probably start by making a new struct that is a copy of multiboot_info, extend and modify fields as necessary, job done. Quite simple, won't be much to argue against when the patches are posted for review, everyone happy. ;) -- Keir > Daniel