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

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



>>> On 21.05.13 at 12:36, Daniel Kiper <daniel.kiper@xxxxxxxxxx> wrote:
> /* Xen Boot Info Arch (XBIA) memory map structure. */
> typedef struct {
>   /*
>    * Amount of lower memory accordingly to The Multiboot
>    * Specification version 0.6.96.
>    */
>   u32 lower;
>   /*
>    * Amount of upper memory accordingly to The Multiboot
>    * Specification version 0.6.96.
>    */
>   u32 upper;
>   u32 map_size;
>   struct e820entry *e820map;
> } xbia_mem_t;

The concepts of lower, upper, and E820 memory are all very much
tied to x86.

> /* Xen Boot Info Arch (XBIA). */
> typedef struct {
>   EFI_SYSTEM_TABLE *efi_system_table;
>   u64 mps; /* Pointer to MPS. */
>   u64 acpi; /* Pointer to ACPI RSDP. */
>   u64 smbios; /* Pointer to SMBIOS. */
>   xbia_mem_t mem;
>   struct xen_vga_console_info vga_console_info;
>   struct edd_info *edd_info;
> } xbia_t;

As are - I think - MPS, EDD, perhaps SMBIOS, and maybe VGA.

If you want to design anything here (and other than you try to
suggest I don't think booting is really a process that can be made
almost arch neutral/generic), you'd need to completely separate
out any _potentially_ arch specific things, not just those that
today we know are specific to one arch or common between the
only two and a half we support. That may mean that _each_ of
the items above should become a separate one, in which case an
enumeration concept would likely be the better one.

Jan


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


 


Rackspace

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