[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 3/5] xen/x86: Migrate to boot_info structure

On 24/09/14 18:19, Daniel Kiper wrote:
> Break multiboot (v1) protocol dependency. It means that most of Xen code
> (excluding preloader) could be bootloader agnostic and does not need almost
> any knowledge about boot protocol. Additionally, we are able to pass all boot
> data to __start_xen() in one bucket without any side channels. I do not 
> mention
> that we are also able to easily identify boot data in Xen code.
> Here is boot data flow for legacy BIOS platform:
>  BIOS -> GRUB -> multiboot[12]* -> __reloc() -> MBD ->-\
>                                                        /
>         ------<------<------<------<------<------<-----
>          \
>           \
>            ---> __init_boot_info() -> boot_info_mb -> __start_xen() -> 
> boot_info
>           /
>  BIOS ->-/
>   * multiboot2 is not implemented yet. Look for it in later patches.
> Here is boot data flow for EFI platform:
>   EFI -> efi_start() -> boot_info_efi -> __start_xen() -> boot_info
> WARNING: ARM build could be broken by this patch. We need to agree boot_info
> integration into ARM. Personally I think that it is worth storing all data
> from any bootloader and preloader in boot_info on any architecture. This give
> a chance to share more code between architectures. However, every architecture
> should define its own boot_info (in relevant include/asm directory). Despite
> that it looks that some parts of it could be common, e.g.  modules data,
> command line arguments, boot loader name, EFI data, etc., even if types
> would not be the same. So, as it was stated above a lot of code could be
> shared among architectures.
> Signed-off-by: Daniel Kiper <daniel.kiper@xxxxxxxxxx>

This patch is basically unreviewable.  Please split it up more, starting
with misc cleanup such as video.h vs vga.h

e.g. start with

typedef struct {
    /* Boot loader name. */
    char *boot_loader_name;
} boot_info_t;

And make some stub declarations which set and retrieve the loader name

Then over the course of the following patches, move small bits one at a
time into this new structure, such as the command line then memory map,
acpi tables, smbios tables etc.  This should probably be at least 8 patches.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.