xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Ian Campbell <ijc@hellion.org.uk>
To: Julien Grall <julien.grall@linaro.org>
Cc: xen-devel <xen-devel@lists.xen.org>, Fu Wei <fu.wei@linaro.org>,
	linaro-uefi <linaro-uefi@lists.linaro.org>
Subject: Re: [Linaro-uefi] [PATCH] xen: arm: implement generic multiboot compatibility strings (Was: Re: The GRUB multiboot support patch for aarch64(V3.1))
Date: Thu, 05 Jun 2014 17:55:31 +0100	[thread overview]
Message-ID: <1401987331.7269.81.camel@dagon.hellion.org.uk> (raw)
In-Reply-To: <53909CA0.9010407@linaro.org>

On Thu, 2014-06-05 at 17:36 +0100, Julien Grall wrote:
> Hi Ian,
> 
> On 06/05/2014 12:56 PM, Ian Campbell wrote:
> > On Thu, 2014-06-05 at 15:46 +0800, Fu Wei wrote:
> >>> I can see why you did this (it's what Xen actually supports today) but I
> >>> wonder if in the interests of reducing the special cases I should create
> >>> a Xen patch which causes it to accept both names so that you can just
> >>> implement the "multiboot,*" stuff in common code without the special
> >>> cases? (Although that depends on the reason for the other non-compat
> >>> string special cases too)
> >>
> >> I think the "multiboot,*" stuff will be better, once Xen supports
> >> this, I will update this code.
> > 
> > I've only compile tested this, but I *think* this does the right thing.
> > 
> > Ian.
> > 
> > 8<-----------------
> > 
> > From d0acce53a086869420c2d8870d1a8a058013d6b5 Mon Sep 17 00:00:00 2001
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Wed, 4 Jun 2014 18:17:10 +0100
> > Subject: [PATCH] xen: arm: implement generic multiboot compatibility strings
> > 
> > This causes Xen to accept the more generic names originally proposed by
> > Andre in http://thread.gmane.org/gmane.linux.linaro.announce.boot/326 and
> > incorporated into the proposal in
> > http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
> > 
> > This will allow bootloaders to not special case Xen (or at least to reduce
> > the amount which is required).
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/common/device_tree.c | 9 ++++++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> > index f0b17a3..5040097 100644
> > --- a/xen/common/device_tree.c
> > +++ b/xen/common/device_tree.c
> > @@ -338,9 +338,11 @@ static void __init process_multiboot_node(const void *fdt, int node,
> >      struct dt_mb_module *mod;
> >      int len;
> >  
> > -    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 )
> > +    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
> > +         fdt_node_check_compatible(fdt, node, "multiboot,linux-zimage") == 0 )
> 
> While we are modifying the protocol, "linux-zImage" is confusing in the
> name. Actually we can use it for an ELF, another OS... I don't think Xen
> will change his behavior depending of the DOM0 image.

zImage defines the boot protocol to use. Since the protocol is defined
by Linux as zImage I think that is the appropriate name, if some other
OS wants to mimic Linux then fine. But if we end up supporting some OS
with its own  boot protocol which doesn't match Linux's then that should
have a distinct name of its own.

The "ELF boot protocol" is as yet undefined. It may or may not end up
resembling zImage. In any case it will be a standard made up entirely by
us and as such xen-elf or something would be the correct name (unless it
happens to match zImage).

> I would rename it to something more generic such as "multiboot,kernel".
> This will avoid adding a new compatible string every time we support a
> new format/OS.

That implies that there is some sort of standard kernel boot interface,
which is not the case, the protocol is defined as linux-zimage.

Perhaps there is scope for a generic compat name which probes based on
magic numbers. You are free to propose and implement such a thing if you
like, but it would be inappropriate to use that with the current
implementation I think.

Ian.

  reply	other threads:[~2014-06-05 16:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <536A1FCF.50207@linaro.org>
     [not found] ` <1401899819.15729.44.camel@hastur.hellion.org.uk>
     [not found]   ` <5390205B.5060803@linaro.org>
2014-06-05 11:56     ` [PATCH] xen: arm: implement generic multiboot compatibility strings (Was: Re: [Linaro-uefi] The GRUB multiboot support patch for aarch64(V3.1)) Ian Campbell
2014-06-05 16:36       ` Julien Grall
2014-06-05 16:55         ` Ian Campbell [this message]
2014-06-05 17:03           ` [Linaro-uefi] [PATCH] xen: arm: implement generic multiboot compatibility strings (Was: " Julien Grall
2014-06-05 18:11             ` Ian Campbell
2014-06-05 18:31             ` Ian Campbell
2014-06-05 21:00               ` Julien Grall
2014-06-06 11:47                 ` Ian Campbell
2014-06-06 12:57                   ` Fu Wei
2014-06-06 12:24               ` Fu Wei
2014-06-06 12:28                 ` Julien Grall
2014-06-06 12:32                   ` Ian Campbell
2014-06-06 13:25                     ` Julien Grall
2014-06-06 14:24                       ` Ian Campbell
2014-06-07 14:07                         ` Julien Grall
2014-06-05 17:05           ` Leif Lindholm
2014-06-05 18:01             ` Ian Campbell

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=1401987331.7269.81.camel@dagon.hellion.org.uk \
    --to=ijc@hellion.org.uk \
    --cc=fu.wei@linaro.org \
    --cc=julien.grall@linaro.org \
    --cc=linaro-uefi@lists.linaro.org \
    --cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).