[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH for-xen-4.5 v4 00/18] xen: Break multiboot (v1) dependency and add multiboot2 support
- To: Jan Beulich <JBeulich@xxxxxxxx>
- From: konrad wilk <konrad.wilk@xxxxxxxxxx>
- Date: Thu, 23 Oct 2014 13:55:57 -0400
- Cc: Juergen Gross <JGross@xxxxxxxx>, keir@xxxxxxx, ian.campbell@xxxxxxxxxx, stefano.stabellini@xxxxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Daniel Kiper <daniel.kiper@xxxxxxxxxx>, roy.franz@xxxxxxxxxx, ning.sun@xxxxxxxxx, ross.philipson@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, qiaowei.ren@xxxxxxxxx, richard.l.maliszewski@xxxxxxxxx, gang.wei@xxxxxxxxx, fu.wei@xxxxxxxxxx
- Delivery-date: Thu, 23 Oct 2014 17:56:37 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On 10/23/2014 12:04 PM, Jan Beulich wrote:
On 23.10.14 at 17:50, <daniel.kiper@xxxxxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
