Re: [Xen-devel] [PATCH for-xen-4.5 v4 00/18] xen: Break multiboot (v1) dependency and add multiboot2 support

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.10.14 at 16:57, <daniel.kiper@xxxxxxxxxx> wrote:
> multiboot1 and multiboot2 are completely different things. If we do what
> you suggest then at least we will be forced to complicate assembly code
> parsing cmdline in xen/arch/x86/boot/cmdline.S. We could also stay with
> multiboot1 stuff but then we will be forced to put all stuff which we are
> able to put in multiboot1. However, we are not able to put at least 
> EFI_HANDLE
> and EFI_SYSTEM_TABLE from multiboot2 (which are a must on EFI; maybe we
> want other data from multiboot2 protocol too) in multiboot1 struct because
> there is not designed place for that. It means that we must add another
> global variables which will appear from nowhere in Xen code (as usual
> in case of global variables).

There's nothing wrong with adding global variables, even less so
when they're __initdata.

> I understand that gains are not clearly visible at this stage of development
> because there is lack of relevant multiboot2 + EFI code on top of this 
> patches.
> However, I hope that above explanation and earlier ones will clear some
> of your doubts.
> 
> Guys, if you wish I can do what Jan suggest. However, personally I think
> that it will complicate things more which are already complicated enough.
> I can understand that Xen was tied to multiboot1 protocol at early stage of
> development. Even I am able to understand that this thing was not changed
> during introduction of EFI code. However, I think that right know, when we
> introduce third boot protocol, mutliboot2, there is not longer any excuse to
> have it build in early and in main Xen code especially. So, IMO we should
> do all cleanups and fixes first and then put all multiboot2 + EFI stuff
> on top of it. If we reverse the order then I do not believe that cleanup
> will be done in foreseeable future.

Repeating the same arguments over and over won't make them any
better. And if MB1, MB2, and EFI are (reasonably) separate rather than
all intermixed, maybe that's going to be the more maintainable state in
the end anyway? We just can't tell without the MB2 pieces (separately)
in place yet.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel