From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752828AbdBPCHX (ORCPT <rfc822;w@1wt.eu>);
        Wed, 15 Feb 2017 21:07:23 -0500
Received: from mga03.intel.com ([134.134.136.65]:24975 "EHLO mga03.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752334AbdBPCHW (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 15 Feb 2017 21:07:22 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.35,167,1484035200"; 
   d="scan'208";a="65737633"
Message-ID: <1487210836.3019.2.camel@linux.intel.com>
Subject: Re: [RFC PATCH] x86/boot: make ELF kernel multiboot-able
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>
Date: Thu, 16 Feb 2017 10:07:16 +0800
In-Reply-To: <CD624531-B4B4-4256-B854-76452AEB90D0@zytor.com>
References: <1487169716-58415-1-git-send-email-chao.p.peng@linux.intel.com>
         <60323D2A-BB58-4112-B21C-62D7A483F2D3@zytor.com>
         <20170215201336.GA24047@wotan.suse.de>
         <CD624531-B4B4-4256-B854-76452AEB90D0@zytor.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


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