| Message ID | 1405945096.25022.46.camel@kazak.uk.xensource.com |
|---|---|
| State | Accepted |
| Commit | 737a54a5903e44125681fcca6727181b0e64ce99 |
| Headers | show |
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@citrix.com> >>>> >>>> Acked-by: Julien Grall <julien.grall@linaro.org> >>> >>> 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@citrix.com> > 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@citrix.com> > --- > 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. With that: Acked-by: Julien Grall <julien.grall@linaro.org> > + 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,
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@citrix.com> > >>>> > >>>> Acked-by: Julien Grall <julien.grall@linaro.org> > >>> > >>> 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@citrix.com> > > 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@citrix.com> > > --- > > 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@linaro.org> > > > + 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, > >
On 07/21/2014 01:26 PM, Ian Campbell wrote: > 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@citrix.com> >>>>>> >>>>>> Acked-by: Julien Grall <julien.grall@linaro.org> >>>>> >>>>> 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@citrix.com> >>> 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@citrix.com> >>> --- >>> 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. Oh right, I forgot there was a paragraph about it. So this change looks good to me. Regards,
On Mon, 2014-07-21 at 13:34 +0100, Julien Grall wrote: > >>> From f9e80ead57b9f739c3041fe5abc4b23c8f0eb18f Mon Sep 17 00:00:00 2001 > >>> From: Ian Campbell <ian.campbell@citrix.com> > >>> 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@citrix.com> > >>> --- > >>> 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. > > Oh right, I forgot there was a paragraph about it. > > So this change looks good to me. May I take that as an Ack?
On 07/24/2014 03:30 PM, Ian Campbell wrote: > On Mon, 2014-07-21 at 13:34 +0100, Julien Grall wrote: >>>>> From f9e80ead57b9f739c3041fe5abc4b23c8f0eb18f Mon Sep 17 00:00:00 2001 >>>>> From: Ian Campbell <ian.campbell@citrix.com> >>>>> 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@citrix.com> >>>>> --- >>>>> 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. >> >> Oh right, I forgot there was a paragraph about it. >> >> So this change looks good to me. > > May I take that as an Ack? I though have acked it on a previous mail... Anyway: Acked-by: Julien Grall <julien.grall@linaro.org> Regards,
On Thu, 2014-07-24 at 15:33 +0100, Julien Grall wrote: > On 07/24/2014 03:30 PM, Ian Campbell wrote: > > On Mon, 2014-07-21 at 13:34 +0100, Julien Grall wrote: > >>>>> From f9e80ead57b9f739c3041fe5abc4b23c8f0eb18f Mon Sep 17 00:00:00 2001 > >>>>> From: Ian Campbell <ian.campbell@citrix.com> > >>>>> 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@citrix.com> > >>>>> --- > >>>>> 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. > >> > >> Oh right, I forgot there was a paragraph about it. > >> > >> So this change looks good to me. > > > > May I take that as an Ack? > > I though have acked it on a previous mail... It was conditional on something which we decided wasn't necessary so I just wanted to make sure. > > Anyway: > > Acked-by: Julien Grall <julien.grall@linaro.org> > > Regards, > >
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 + 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.