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

[Keir Fraser <keir.xen@xxxxxxxxx>]

On 22/05/2013 16:59, "Daniel Kiper" <daniel.kiper@xxxxxxxxxx> wrote:

> On Wed, May 22, 2013 at 04:10:17PM +0100, Jan Beulich wrote:
>>>>> On 22.05.13 at 16:43, Daniel Kiper <daniel.kiper@xxxxxxxxxx> 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



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