Re: [Xen-devel] New Xen boot infrastructure proposal

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Tue, May 21, 2013 at 02:24:37PM +0100, Keir Fraser wrote:
> On 21/05/2013 11:36, "Daniel Kiper" <daniel.kiper@xxxxxxxxxx> wrote:

[...]

> > It should contain all needed stuff, be architecture
> > independent as much as possible and easily extensible.
>
> Why and why? Well I mean we shouldn't make things deliberately architecture
> *dependent*, but where tables and flags need parsing/translating I'd rather
> do that once per architecture, rather than once per bootloader format (which
> I am thinking are mostly arch-dependent, and hence at least as numerous as
> architectures). As for easily extensible, we are talking about communication
> between Xen 'pre-loaders' (we might call them) and Xen proper (eg
> arch/x86/setup.c). Who cares about the hassle of extensible self-describing
> formats here? Just make it a struct and extend the struct, it all gets built
> together as matched sets of pre-loaders and Xen anyway.
>
> I'd be looking for a simple extension to what we have to pass stuff like
> ACPI through, if it's needed at all. Maybe clean things up a bit and work
> out a nice way to mate that with the existing multiboot-centric world. I
> wouldn't waste my time hitting it with the architecture sledgehammer.

I do not insist on using so complicated structure because it has
some weakness which I am aware of. However, I think we should
build our own structure to pass stuff from preloader (mainly
assembly files) to proper Xen. It will be nice if it has place
for other boot stuff collected in __start_xen() too. If we stick
to old multiboot structure it will make diffculties in multiboot2
protocol implementation. For example it will be very difficult to
pass (in sensible way), from preloader to Xen, info about ACPI and EFI
stuff. That is why I think that this new structure should not be
so tightly linked with any boot protocol.

Daniel

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