Re: [Xen-devel] [PATCH v3 09/10] xen: arm: update multiboot device tree bindings.

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2014-07-21 at 13:23 +0100, Julien Grall wrote:
> On 07/21/2014 01:18 PM, Ian Campbell wrote:
> > On Mon, 2014-07-21 at 12:53 +0100, Julien Grall wrote:
> >> On 07/21/2014 12:45 PM, Ian Campbell wrote:
> >>> On Fri, 2014-07-18 at 22:03 +0100, Julien Grall wrote:
> >>>> Hi Ian,
> >>>>
> >>>> On 18/07/14 14:08, Ian Campbell wrote:
> >>>>> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >>>>
> >>>> Acked-by: Julien Grall <julien.grall@xxxxxxxxxx>
> >>>
> >>> Thanks. I've applied patches 1..9 of this series. I'll resend 10 ASAP
> >>> with the change you've suggested.
> >>>
> >>> On my potential backports list I've got:
> >>> xen: arm: implement generic multiboot compatibility strings
> >>> xen: arm: /chosen/module@N/bootargs bootprotcol node is not deprecated
> >>>
> >>> I don't think anything else here is suitable for backport. Let me know
> >>> if you think something is (or isn't)
> >>
> >> I would also update the document bindings in
> >> docs/misc/arm/device-tree/booting.txt.
> >>
> >> The patch #9 looks the good one for this purpose. Minus the unspecified
> >> type example.
> > 
> > I think it is acceptable to point people to the latest version of the
> > doc in the dev branch as the canonical copy.
> > 
> > The latest version already needs to properly describe the mechanisms for
> > backwards compatibility anyway and trying to backport only the docs
> > updates which match backported bits of code is liable to get fiddly
> > quite fast and/or require new patches etc, I'd rather not do this.
> > 
> >> BTW, I don't find anything in the documentation talking about bootmodule
> >> type detection by ordering. Is this intended?
> > 
> > No, I should have done this and forgot, thanks for the reminder. See
> > below.
> > 
> > Ian.
> > 
> > 8<--------------------------
> > 
> > From f9e80ead57b9f739c3041fe5abc4b23c8f0eb18f Mon Sep 17 00:00:00 2001
> > From: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > Date: Mon, 21 Jul 2014 13:16:31 +0100
> > Subject: [PATCH] xen: arm: document boot module compatibility based on
> >  ordering
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > ---
> >  docs/misc/arm/device-tree/booting.txt |    8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/docs/misc/arm/device-tree/booting.txt 
> > b/docs/misc/arm/device-tree/booting.txt
> > index d967061..ad98bf3 100644
> > --- a/docs/misc/arm/device-tree/booting.txt
> > +++ b/docs/misc/arm/device-tree/booting.txt
> > @@ -23,7 +23,13 @@ Each node contains the following properties:
> >     compatible string (if one applies) in addition to the generic
> >     string (which must always be present).
> >  
> > -        Xen 4.4 supported a different set of legacy compatible strings
> > +   Xen will assume that the first module which lacks a more
> 
> With this change, it's not clear that Xen 4.4 doesn't support boot
> module ordering. I would precise Xen 4.5 and onwards.

Note that a paragraph further down still reads:
        For compatibility with Xen 4.4 the more specific "xen,linux-*"
        names are non-optional and must be included.

So I don't think it's necessary to clutter up this new paragraph with
that caveat.

Also note that the apparently remove "Xen 4.4" above is actually just
re-indented, it was the only line not using a hard tab for some reason.

Actually I'd prefer that file to use soft tabs like everything else, but
I wasn't about to do that at the same time...

Ian.

> 
> With that:
> 
> Acked-by: Julien Grall <julien.grall@xxxxxxxxxx>
> 
> > +   specific compatible string is a "multiboot,kernel" and that
> > +   the second such is a "multiboot,ramdisk". Any subsequent
> > +   modules which lack a specific compatiblity string will not
> > +   receive any special treatment.
> > +
> > +   Xen 4.4 supported a different set of legacy compatible strings
> >     which remain supported such that systems supporting both 4.4
> >     and later can use a single DTB.
> >  
> > 
> 
> Regards,
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel