All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Peng <chao.p.peng@linux.intel.com>
To: hpa@zytor.com, "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, grub-devel@gnu.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Andy Lutomirski <luto@kernel.org>,
	Juergen Gross <jgross@suse.com>, Borislav Petkov <bp@suse.de>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Thomas Garnier <thgarnie@google.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Amnon Ilan <ailan@redhat.com>, Alexander Graf <agraf@suse.de>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	Daniel Kiper <daniel.kiper@oracle.com>
Subject: Re: [RFC PATCH] x86/boot: make ELF kernel multiboot-able
Date: Thu, 16 Feb 2017 10:07:16 +0800	[thread overview]
Message-ID: <1487210836.3019.2.camel@linux.intel.com> (raw)
In-Reply-To: <CD624531-B4B4-4256-B854-76452AEB90D0@zytor.com>


> > Just something to consider, provided the issues with multiboot get
> > resolved:
> > 
> > If you want to boot Xen you actually use the multiboot protocol, the
> > last PVH
> > boot patches had borrowed ideas from Multiboot to add an entry to
> > Linux, only
> > it was Xen'ified. What would be Multiboot 2 seemed flexible enough to
> > allow all
> > sorts of custom semantics and information stacked into a boot image.
> > The last
> > thought I had over this topic (before giving up)  was-- if we're going
> > to add
> > yet-another-entry (TM) why not add extend Mulitiboot 2 protocol with
> > the
> > semantics we need to boot any virtual environment and then add
> > Multiboot 2
> > support entry on Linux? We could redirect any custom boot mechanism
> > then to
> > just use that given its flexibility.
> > 
> >  Luis
> 
> Multiboot has a fundamentally broken assumption, which is to do certain work for the kernel in the
> bootloader.  This is fundamentally a bad idea, because you always want to do things in the latest
> step possible during the boot process, being the most upgradeable, and have the interface as
> narrow as possible.
> 
> Therefore, using Multiboot is actively a negative step.  It is declared an "Open Standard" but
> anything can be such declared; it really is a claim that "everything should work like Grub."

Thanks Peter and Luis for comments.

Chao


  reply	other threads:[~2017-02-16  2:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-15 14:41 [RFC PATCH] x86/boot: make ELF kernel multiboot-able Chao Peng
2017-02-15 16:42 ` Paolo Bonzini
2017-02-16  2:12   ` Chao Peng
2017-02-15 18:12 ` hpa
2017-02-15 20:13   ` Luis R. Rodriguez
2017-02-15 20:58     ` hpa
2017-02-16  2:07       ` Chao Peng [this message]
2017-02-16 23:27       ` Daniel Kiper
2017-02-17  5:00         ` H. Peter Anvin
2017-02-20 18:46           ` 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=1487210836.3019.2.camel@linux.intel.com \
    --to=chao.p.peng@linux.intel.com \
    --cc=agraf@suse.de \
    --cc=ailan@redhat.com \
    --cc=bp@suse.de \
    --cc=daniel.kiper@oracle.com \
    --cc=grub-devel@gnu.org \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mcgrof@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thgarnie@google.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@kernel.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.