All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xensource.com, keir@xen.org,
	ian.campbell@citrix.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com,
	Keir Fraser <keir.xen@gmail.com>
Subject: Re: New Xen boot infrastructure proposal
Date: Wed, 22 May 2013 17:59:16 +0200	[thread overview]
Message-ID: <20130522155916.GG25607@debian70-amd64.local.net-space.pl> (raw)
In-Reply-To: <519CFBF902000078000D82A3@nat28.tlf.novell.com>

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

Daniel

  reply	other threads:[~2013-05-22 15:59 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-21 10:36 New Xen boot infrastructure proposal Daniel Kiper
2013-05-21 11:39 ` Stefano Stabellini
2013-05-21 12:57   ` Daniel Kiper
2013-05-21 12:03 ` Jan Beulich
2013-05-22 14:09   ` Daniel Kiper
2013-05-22 14:33     ` Jan Beulich
2013-05-22 15:01       ` Daniel Kiper
2013-05-22 15:16         ` Jan Beulich
2013-05-22 16:47           ` Konrad Rzeszutek Wilk
2013-05-22 16:56             ` Keir Fraser
2013-05-23  6:37             ` Jan Beulich
2013-05-21 12:43 ` David Vrabel
2013-05-22 14:19   ` Daniel Kiper
2013-05-21 12:52 ` Ian Campbell
2013-05-22 14:27   ` Daniel Kiper
2013-05-22 14:35     ` Jan Beulich
2013-05-22 15:09     ` Ian Campbell
2013-05-22 15:25       ` Ian Campbell
2013-05-22 15:34         ` Daniel Kiper
2013-05-22 15:41           ` Ian Campbell
2013-05-22 16:19             ` Daniel Kiper
2013-05-23 13:33               ` Ian Campbell
2013-05-21 13:24 ` Keir Fraser
2013-05-22 14:43   ` Daniel Kiper
2013-05-22 15:10     ` Jan Beulich
2013-05-22 15:59       ` Daniel Kiper [this message]
2013-05-22 16:40         ` Keir Fraser

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=20130522155916.GG25607@debian70-amd64.local.net-space.pl \
    --to=daniel.kiper@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=ian.campbell@citrix.com \
    --cc=keir.xen@gmail.com \
    --cc=keir@xen.org \
    --cc=konrad.wilk@oracle.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /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.