All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Daniel Kiper <daniel.kiper@oracle.com>, xen-devel@lists.xenproject.org
Cc: keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	ning.sun@intel.com, jbeulich@suse.com, ross.philipson@citrix.com,
	qiaowei.ren@intel.com, richard.l.maliszewski@intel.com,
	gang.wei@intel.com, fu.wei@linaro.org
Subject: Re: [PATCH v2 3/5] xen/x86: Migrate to boot_info structure
Date: Wed, 24 Sep 2014 20:00:09 +0100	[thread overview]
Message-ID: <542314B9.1040105@citrix.com> (raw)
In-Reply-To: <1411579162-27503-4-git-send-email-daniel.kiper@oracle.com>

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@oracle.com>

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
alone.

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.

~Andrew

  reply	other threads:[~2014-09-24 19:00 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-24 17:19 [PATCH v2 0/5] xen: Break multiboot (v1) dependency and add multiboot2 support Daniel Kiper
2014-09-24 17:19 ` [PATCH v2 1/5] xen/x86: Introduce MultiBoot Data (MBD) type Daniel Kiper
2014-09-24 18:40   ` Andrew Cooper
2014-09-25  9:22     ` Jan Beulich
2014-09-25 12:56       ` Daniel Kiper
2014-09-25 13:24         ` Jan Beulich
2014-09-25 19:24     ` Daniel Kiper
2014-09-26  8:13       ` Jan Beulich
2014-09-24 17:19 ` [PATCH v2 2/5] xen/x86: Define e820 entries counter as unsigned int Daniel Kiper
2014-09-24 18:10   ` Andrew Cooper
2014-09-24 17:19 ` [PATCH v2 3/5] xen/x86: Migrate to boot_info structure Daniel Kiper
2014-09-24 19:00   ` Andrew Cooper [this message]
2014-09-25  9:43   ` Ian Campbell
2014-09-25 12:32     ` Daniel Kiper
2014-09-24 17:19 ` [PATCH v2 4/5] xen/x86: Use constant as multiboot protocol identifier Daniel Kiper
2014-09-24 18:11   ` Andrew Cooper
2014-09-24 17:19 ` [PATCH v2 5/5] xen/x86: Add multiboot2 protocol support Daniel Kiper
2014-09-24 19:14   ` Andrew Cooper
2014-09-25 18:42     ` Daniel Kiper
2014-09-25 18:52       ` Andrew Cooper
2014-09-24 17:48 ` [PATCH v2 0/5] xen: Break multiboot (v1) dependency and add multiboot2 support Roy Franz
2014-09-25  9:15   ` Jan Beulich
2014-09-25  9:45     ` Ian Campbell
2014-09-25 13:01     ` Daniel Kiper
2014-09-25 15:56       ` Roy Franz
2014-09-25 19:47         ` Daniel Kiper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=542314B9.1040105@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=daniel.kiper@oracle.com \
    --cc=fu.wei@linaro.org \
    --cc=gang.wei@intel.com \
    --cc=ian.campbell@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=ning.sun@intel.com \
    --cc=qiaowei.ren@intel.com \
    --cc=richard.l.maliszewski@intel.com \
    --cc=ross.philipson@citrix.com \
    --cc=roy.franz@linaro.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.