diff mbox

[Xen-devel] build: Conditional build/clean/distclean targets on subsystems

Message ID 1367574808.28742.53.camel@zakaz.uk.xensource.com
State New
Headers show

Commit Message

Ian Campbell May 3, 2013, 9:53 a.m. UTC
On Fri, 2013-05-03 at 09:43 +0100, Ian Campbell wrote:
> On Fri, 2013-05-03 at 08:15 +0100, Jan Beulich wrote:
> > >>> On 03.05.13 at 01:17, Julien Grall <julien.grall@linaro.org> wrote:
> > > The commit 3378685 "Add conditional build of subsystems to configure.ac"
> > > allows the user to disable/enable some components of Xen. After this commit
> > > some targets are still called on every subsystems.
> > 
> > For build this is correct to do, but for any clean target it isn't - clean
> > should remove leftovers from earlier builds even if there was an
> > intermediate reconfigure.
> 
> Yes, I think so too.
> 
> > > For Xen on ARM, the makefile targets build, clean and distclean will failed.
> > 
> > If they fail, this will need fixing elsewhere then.
> 
> Part of the issue is that there are targets which are simply not ported
> to  ARM and therefore are missing bits of infrastructure , e.g. mini-os
> where one if the clean failures is lack of
> extras/mini-os/arch/arm/arch.mk.
> 
> However I think it is wrong to tie the clean/distclean of these into the
> configurey selection mechanism, i.e. mini-os should know that it only
> support x86 (for the minute) and DTRT when called for ARM (which is
> likely to be nothing much). Perhaps a stub
> extras/mini-os/arch/arm/arch.mk is the answer?
> 
> The other case is the kernel distclean, which fails with 
>         buildconfigs/mk.linux-2.6-common:32: buildconfigs/src.: No such file or directory
> but that seems to fail on x86 too. Having disabled it by default so long
> ago perhaps the time has come to simply remove this stuff? I don't know
> if anyone is still using it -- the test system perhaps?
> 
> Or it could be fixed with the below, I think.
> 
> Ian.
> 
> 8<---------------------
> 
> build: fix kernel build rules.
> 
> Rename mk.linux-2.6-common to common.linux-2.6 so that it does not get
> included in the ALLKERNELS logic.
> 
> Specify XEN_LINUX_SOURCE for linux-2.6-native, looking at 414614d84e67
> and todays linux-2.6-xen.mk I am guessing that hg-clone of the 2.6.18
> tree is the expected method. To be honest I didn't even try it...
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> NB git diff -M style diff, includes the rename...
> 
>  .../{mk.linux-2.6-common => common.linux-2.6}      |    0
>  buildconfigs/mk.linux-2.6                          |    2 +-
>  buildconfigs/mk.linux-2.6-native                   |    3 ++-
>  buildconfigs/mk.linux-2.6-pvops                    |    2 +-
>  buildconfigs/mk.linux-2.6-tip-latest               |    2 +-
>  buildconfigs/mk.linux-2.6-xen                      |    2 +-
>  6 files changed, 6 insertions(+), 5 deletions(-)

Ahem....

8<----------------

Comments

Julien Grall May 3, 2013, 10:52 a.m. UTC | #1
On 05/03/2013 10:53 AM, Ian Campbell wrote:

> On Fri, 2013-05-03 at 09:43 +0100, Ian Campbell wrote:
>> On Fri, 2013-05-03 at 08:15 +0100, Jan Beulich wrote:
>>>>>> On 03.05.13 at 01:17, Julien Grall <julien.grall@linaro.org> wrote:
>>>> The commit 3378685 "Add conditional build of subsystems to configure.ac"
>>>> allows the user to disable/enable some components of Xen. After this commit
>>>> some targets are still called on every subsystems.
>>>
>>> For build this is correct to do, but for any clean target it isn't - clean
>>> should remove leftovers from earlier builds even if there was an
>>> intermediate reconfigure.
>>
>> Yes, I think so too.
>>
>>>> For Xen on ARM, the makefile targets build, clean and distclean will failed.
>>>
>>> If they fail, this will need fixing elsewhere then.
>>
>> Part of the issue is that there are targets which are simply not ported
>> to  ARM and therefore are missing bits of infrastructure , e.g. mini-os
>> where one if the clean failures is lack of
>> extras/mini-os/arch/arm/arch.mk.
>>
>> However I think it is wrong to tie the clean/distclean of these into the
>> configurey selection mechanism, i.e. mini-os should know that it only
>> support x86 (for the minute) and DTRT when called for ARM (which is
>> likely to be nothing much). Perhaps a stub
>> extras/mini-os/arch/arm/arch.mk is the answer?
>>
>> The other case is the kernel distclean, which fails with 
>>         buildconfigs/mk.linux-2.6-common:32: buildconfigs/src.: No such file or directory
>> but that seems to fail on x86 too. Having disabled it by default so long
>> ago perhaps the time has come to simply remove this stuff? I don't know
>> if anyone is still using it -- the test system perhaps?
>>
>> Or it could be fixed with the below, I think.
>>
>> Ian.
>>
>> 8<---------------------
>>
>> build: fix kernel build rules.
>>
>> Rename mk.linux-2.6-common to common.linux-2.6 so that it does not get
>> included in the ALLKERNELS logic.
>>
>> Specify XEN_LINUX_SOURCE for linux-2.6-native, looking at 414614d84e67
>> and todays linux-2.6-xen.mk I am guessing that hg-clone of the 2.6.18
>> tree is the expected method. To be honest I didn't even try it...
>>
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> ---
>> NB git diff -M style diff, includes the rename...
>>
>>  .../{mk.linux-2.6-common => common.linux-2.6}      |    0
>>  buildconfigs/mk.linux-2.6                          |    2 +-
>>  buildconfigs/mk.linux-2.6-native                   |    3 ++-
>>  buildconfigs/mk.linux-2.6-pvops                    |    2 +-
>>  buildconfigs/mk.linux-2.6-tip-latest               |    2 +-
>>  buildconfigs/mk.linux-2.6-xen                      |    2 +-
>>  6 files changed, 6 insertions(+), 5 deletions(-)
> 
> Ahem....
> 
> 8<----------------
> 
> diff --git a/buildconfigs/mk.linux-2.6-common b/buildconfigs/common.linux-2.6
> similarity index 100%
> rename from buildconfigs/mk.linux-2.6-common
> rename to buildconfigs/common.linux-2.6
> diff --git a/buildconfigs/mk.linux-2.6 b/buildconfigs/mk.linux-2.6
> index 6b8d989..6523afb 100644
> --- a/buildconfigs/mk.linux-2.6
> +++ b/buildconfigs/mk.linux-2.6
> @@ -7,4 +7,4 @@ XEN_LINUX_CONFIG_UPDATE := buildconfigs/enable-xen-config
>  
>  EXTRAVERSION ?=
>  
> -include buildconfigs/mk.linux-2.6-common
> +include buildconfigs/common.linux-2.6
> diff --git a/buildconfigs/mk.linux-2.6-native b/buildconfigs/mk.linux-2.6-native
> index c7c0949..6e2a77b 100644
> --- a/buildconfigs/mk.linux-2.6-native
> +++ b/buildconfigs/mk.linux-2.6-native
> @@ -1,5 +1,7 @@
>  EXTRAVERSION = -native
>  IMAGE_TARGET = bzImage
>  INSTALL_BOOT_PATH = $(DESTDIR)/boot
> +LINUX_VER    ?= 2.6.18
> +XEN_LINUX_SOURCE ?= hg-clone
>  
> -include buildconfigs/mk.linux-2.6-common
> +include buildconfigs/common.linux-2.6
> diff --git a/buildconfigs/mk.linux-2.6-pvops b/buildconfigs/mk.linux-2.6-pvops
> index 59cae79..9a11c7d 100644
> --- a/buildconfigs/mk.linux-2.6-pvops
> +++ b/buildconfigs/mk.linux-2.6-pvops
> @@ -14,4 +14,4 @@ XEN_LINUX_GIT_REMOTEBRANCH ?= xen/stable-2.6.32.x
>  
>  EXTRAVERSION ?=
>  
> -include buildconfigs/mk.linux-2.6-common
> +include buildconfigs/common.linux-2.6
> diff --git a/buildconfigs/mk.linux-2.6-tip-latest b/buildconfigs/mk.linux-2.6-tip-latest
> index 2a0b9af..158dda0 100644
> --- a/buildconfigs/mk.linux-2.6-tip-latest
> +++ b/buildconfigs/mk.linux-2.6-tip-latest
> @@ -14,4 +14,4 @@ XEN_LINUX_GIT_REMOTEBRANCH ?= auto-latest
>  
>  EXTRAVERSION ?=
>  
> -include buildconfigs/mk.linux-2.6-common
> +include buildconfigs/common.linux-2.6
> diff --git a/buildconfigs/mk.linux-2.6-xen b/buildconfigs/mk.linux-2.6-xen
> index 8594b55..b1facb6 100644
> --- a/buildconfigs/mk.linux-2.6-xen
> +++ b/buildconfigs/mk.linux-2.6-xen
> @@ -3,4 +3,4 @@ LINUX_VER    ?= 2.6.18
>  
>  XEN_LINUX_SOURCE ?= hg-clone
>  
> -include buildconfigs/mk.linux-2.6-common
> +include buildconfigs/common.linux-2.6


Hum in fact, it seems the build target doesn't work because

make[3]: Leaving directory `/local/scratch/julieng/xen-unstable/xen/arch/arm'
gzip -f -9 < /local/scratch/julieng/xen-unstable/xen/xen > /local/scratch/julieng/xen-unstable/xen/xen.gz.new
mv /local/scratch/julieng/xen-unstable/xen/xen.gz.new /local/scratch/julieng/xen-unstable/xen/xen.gz
make[2]: Leaving directory `/local/scratch/julieng/xen-unstable/xen'
make[1]: Leaving directory `/local/scratch/julieng/xen-unstable/xen'
make -C tools build
make[1]: Entering directory `/local/scratch/julieng/xen-unstable/tools'
make[1]: *** No rule to make target `build'.  Stop.
make[1]: Leaving directory `/local/scratch/julieng/xen-unstable/tools'
make: *** [build] Error 2

The target build is missing in tools build. So I guess nobody use it now.
Is it possible to remove this target?
Andrew Cooper May 3, 2013, 11:13 a.m. UTC | #2
On 03/05/2013 11:52, Julien Grall wrote:
> On 05/03/2013 10:53 AM, Ian Campbell wrote:
>
>> On Fri, 2013-05-03 at 09:43 +0100, Ian Campbell wrote:
>>> On Fri, 2013-05-03 at 08:15 +0100, Jan Beulich wrote:
>>>>>>> On 03.05.13 at 01:17, Julien Grall <julien.grall@linaro.org> wrote:
>>>>> The commit 3378685 "Add conditional build of subsystems to configure.ac"
>>>>> allows the user to disable/enable some components of Xen. After this commit
>>>>> some targets are still called on every subsystems.
>>>> For build this is correct to do, but for any clean target it isn't - clean
>>>> should remove leftovers from earlier builds even if there was an
>>>> intermediate reconfigure.
>>> Yes, I think so too.
>>>
>>>>> For Xen on ARM, the makefile targets build, clean and distclean will failed.
>>>> If they fail, this will need fixing elsewhere then.
>>> Part of the issue is that there are targets which are simply not ported
>>> to  ARM and therefore are missing bits of infrastructure , e.g. mini-os
>>> where one if the clean failures is lack of
>>> extras/mini-os/arch/arm/arch.mk.
>>>
>>> However I think it is wrong to tie the clean/distclean of these into the
>>> configurey selection mechanism, i.e. mini-os should know that it only
>>> support x86 (for the minute) and DTRT when called for ARM (which is
>>> likely to be nothing much). Perhaps a stub
>>> extras/mini-os/arch/arm/arch.mk is the answer?
>>>
>>> The other case is the kernel distclean, which fails with 
>>>         buildconfigs/mk.linux-2.6-common:32: buildconfigs/src.: No such file or directory
>>> but that seems to fail on x86 too. Having disabled it by default so long
>>> ago perhaps the time has come to simply remove this stuff? I don't know
>>> if anyone is still using it -- the test system perhaps?
>>>
>>> Or it could be fixed with the below, I think.
>>>
>>> Ian.
>>>
>>> 8<---------------------
>>>
>>> build: fix kernel build rules.
>>>
>>> Rename mk.linux-2.6-common to common.linux-2.6 so that it does not get
>>> included in the ALLKERNELS logic.
>>>
>>> Specify XEN_LINUX_SOURCE for linux-2.6-native, looking at 414614d84e67
>>> and todays linux-2.6-xen.mk I am guessing that hg-clone of the 2.6.18
>>> tree is the expected method. To be honest I didn't even try it...
>>>
>>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>>> ---
>>> NB git diff -M style diff, includes the rename...
>>>
>>>  .../{mk.linux-2.6-common => common.linux-2.6}      |    0
>>>  buildconfigs/mk.linux-2.6                          |    2 +-
>>>  buildconfigs/mk.linux-2.6-native                   |    3 ++-
>>>  buildconfigs/mk.linux-2.6-pvops                    |    2 +-
>>>  buildconfigs/mk.linux-2.6-tip-latest               |    2 +-
>>>  buildconfigs/mk.linux-2.6-xen                      |    2 +-
>>>  6 files changed, 6 insertions(+), 5 deletions(-)
>> Ahem....
>>
>> 8<----------------
>>
>> diff --git a/buildconfigs/mk.linux-2.6-common b/buildconfigs/common.linux-2.6
>> similarity index 100%
>> rename from buildconfigs/mk.linux-2.6-common
>> rename to buildconfigs/common.linux-2.6
>> diff --git a/buildconfigs/mk.linux-2.6 b/buildconfigs/mk.linux-2.6
>> index 6b8d989..6523afb 100644
>> --- a/buildconfigs/mk.linux-2.6
>> +++ b/buildconfigs/mk.linux-2.6
>> @@ -7,4 +7,4 @@ XEN_LINUX_CONFIG_UPDATE := buildconfigs/enable-xen-config
>>  
>>  EXTRAVERSION ?=
>>  
>> -include buildconfigs/mk.linux-2.6-common
>> +include buildconfigs/common.linux-2.6
>> diff --git a/buildconfigs/mk.linux-2.6-native b/buildconfigs/mk.linux-2.6-native
>> index c7c0949..6e2a77b 100644
>> --- a/buildconfigs/mk.linux-2.6-native
>> +++ b/buildconfigs/mk.linux-2.6-native
>> @@ -1,5 +1,7 @@
>>  EXTRAVERSION = -native
>>  IMAGE_TARGET = bzImage
>>  INSTALL_BOOT_PATH = $(DESTDIR)/boot
>> +LINUX_VER    ?= 2.6.18
>> +XEN_LINUX_SOURCE ?= hg-clone
>>  
>> -include buildconfigs/mk.linux-2.6-common
>> +include buildconfigs/common.linux-2.6
>> diff --git a/buildconfigs/mk.linux-2.6-pvops b/buildconfigs/mk.linux-2.6-pvops
>> index 59cae79..9a11c7d 100644
>> --- a/buildconfigs/mk.linux-2.6-pvops
>> +++ b/buildconfigs/mk.linux-2.6-pvops
>> @@ -14,4 +14,4 @@ XEN_LINUX_GIT_REMOTEBRANCH ?= xen/stable-2.6.32.x
>>  
>>  EXTRAVERSION ?=
>>  
>> -include buildconfigs/mk.linux-2.6-common
>> +include buildconfigs/common.linux-2.6
>> diff --git a/buildconfigs/mk.linux-2.6-tip-latest b/buildconfigs/mk.linux-2.6-tip-latest
>> index 2a0b9af..158dda0 100644
>> --- a/buildconfigs/mk.linux-2.6-tip-latest
>> +++ b/buildconfigs/mk.linux-2.6-tip-latest
>> @@ -14,4 +14,4 @@ XEN_LINUX_GIT_REMOTEBRANCH ?= auto-latest
>>  
>>  EXTRAVERSION ?=
>>  
>> -include buildconfigs/mk.linux-2.6-common
>> +include buildconfigs/common.linux-2.6
>> diff --git a/buildconfigs/mk.linux-2.6-xen b/buildconfigs/mk.linux-2.6-xen
>> index 8594b55..b1facb6 100644
>> --- a/buildconfigs/mk.linux-2.6-xen
>> +++ b/buildconfigs/mk.linux-2.6-xen
>> @@ -3,4 +3,4 @@ LINUX_VER    ?= 2.6.18
>>  
>>  XEN_LINUX_SOURCE ?= hg-clone
>>  
>> -include buildconfigs/mk.linux-2.6-common
>> +include buildconfigs/common.linux-2.6
>
> Hum in fact, it seems the build target doesn't work because
>
> make[3]: Leaving directory `/local/scratch/julieng/xen-unstable/xen/arch/arm'
> gzip -f -9 < /local/scratch/julieng/xen-unstable/xen/xen > /local/scratch/julieng/xen-unstable/xen/xen.gz.new
> mv /local/scratch/julieng/xen-unstable/xen/xen.gz.new /local/scratch/julieng/xen-unstable/xen/xen.gz
> make[2]: Leaving directory `/local/scratch/julieng/xen-unstable/xen'
> make[1]: Leaving directory `/local/scratch/julieng/xen-unstable/xen'
> make -C tools build
> make[1]: Entering directory `/local/scratch/julieng/xen-unstable/tools'
> make[1]: *** No rule to make target `build'.  Stop.
> make[1]: Leaving directory `/local/scratch/julieng/xen-unstable/tools'
> make: *** [build] Error 2
>
> The target build is missing in tools build. So I guess nobody use it now.
> Is it possible to remove this target?
>

I did attempt to fix this before with
http://lists.xen.org/archives/html/xen-devel/2012-08/msg00134.html

Please allow this to constitute a "ping" regarding the patch on that email.

~Andrew
Ian Jackson May 7, 2013, 5:27 p.m. UTC | #3
Andrew Cooper writes ("Re: [Xen-devel] [PATCH] build: Conditional build/clean/distclean targets on subsystems"):
> I did attempt to fix this before with
> http://lists.xen.org/archives/html/xen-devel/2012-08/msg00134.html
> 
> Please allow this to constitute a "ping" regarding the patch on that email.

We had a little thread about this then.

At the time I thought we also needed this patch, before yours:
  http://lists.xen.org/archives/html/xen-devel/2012-08/msg00870.html

It looks from that thread like I was hoping for an ack from someone
else on my patch.

These look like bugfixes to me.  George, are they OK for 4.3 ?

Ian.
George Dunlap May 8, 2013, 10:22 a.m. UTC | #4
On Tue, May 7, 2013 at 6:27 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH] build: Conditional build/clean/distclean targets on subsystems"):
>> I did attempt to fix this before with
>> http://lists.xen.org/archives/html/xen-devel/2012-08/msg00134.html
>>
>> Please allow this to constitute a "ping" regarding the patch on that email.
>
> We had a little thread about this then.
>
> At the time I thought we also needed this patch, before yours:
>   http://lists.xen.org/archives/html/xen-devel/2012-08/msg00870.html
>
> It looks from that thread like I was hoping for an ack from someone
> else on my patch.
>
> These look like bugfixes to me.  George, are they OK for 4.3 ?

Hrm, I'm not terribly happy about this kind of change this late in the
day, but I think overall it's best to fix this.

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Ian Campbell May 8, 2013, 11:18 a.m. UTC | #5
On Wed, 2013-05-08 at 11:22 +0100, George Dunlap wrote:
> On Tue, May 7, 2013 at 6:27 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > Andrew Cooper writes ("Re: [Xen-devel] [PATCH] build: Conditional build/clean/distclean targets on subsystems"):
> >> I did attempt to fix this before with
> >> http://lists.xen.org/archives/html/xen-devel/2012-08/msg00134.html
> >>
> >> Please allow this to constitute a "ping" regarding the patch on that email.
> >
> > We had a little thread about this then.
> >
> > At the time I thought we also needed this patch, before yours:
> >   http://lists.xen.org/archives/html/xen-devel/2012-08/msg00870.html
> >
> > It looks from that thread like I was hoping for an ack from someone
> > else on my patch.
> >
> > These look like bugfixes to me.  George, are they OK for 4.3 ?
> 
> Hrm, I'm not terribly happy about this kind of change this late in the
> day, but I think overall it's best to fix this.
> 
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

This old mail is long gone from my INBOX, can I get either a resend or a
set of message ids which I can track down?

Also can you both (Ian and George) clarify whether your acks apply to
Andrew's series (or single patch?) from last year or to Julien's patch
or to both.

Ian.
Andrew Cooper May 8, 2013, 12:14 p.m. UTC | #6
On 08/05/13 12:18, Ian Campbell wrote:
> On Wed, 2013-05-08 at 11:22 +0100, George Dunlap wrote:
>> On Tue, May 7, 2013 at 6:27 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>>> Andrew Cooper writes ("Re: [Xen-devel] [PATCH] build: Conditional build/clean/distclean targets on subsystems"):
>>>> I did attempt to fix this before with
>>>> http://lists.xen.org/archives/html/xen-devel/2012-08/msg00134.html
>>>>
>>>> Please allow this to constitute a "ping" regarding the patch on that email.
>>> We had a little thread about this then.
>>>
>>> At the time I thought we also needed this patch, before yours:
>>>   http://lists.xen.org/archives/html/xen-devel/2012-08/msg00870.html
>>>
>>> It looks from that thread like I was hoping for an ack from someone
>>> else on my patch.
>>>
>>> These look like bugfixes to me.  George, are they OK for 4.3 ?
>> Hrm, I'm not terribly happy about this kind of change this late in the
>> day, but I think overall it's best to fix this.
>>
>> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> This old mail is long gone from my INBOX, can I get either a resend or a
> set of message ids which I can track down?
>
> Also can you both (Ian and George) clarify whether your acks apply to
> Andrew's series (or single patch?) from last year or to Julien's patch
> or to both.

Single patch, as far as this is concerned.

~Andrew

>
> Ian.
>
Ian Jackson May 8, 2013, 12:51 p.m. UTC | #7
Andrew Cooper writes ("Re: [Xen-devel] [PATCH] build: Conditional build/clean/distclean targets on subsystems"):
> On 08/05/13 12:18, Ian Campbell wrote:
> > On Wed, 2013-05-08 at 11:22 +0100, George Dunlap wrote:
> >> On Tue, May 7, 2013 at 6:27 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> >>> Andrew Cooper writes ("Re: [Xen-devel] [PATCH] build: Conditional build/clean/distclean targets on subsystems"):
> >>>> I did attempt to fix this before with
> >>>> http://lists.xen.org/archives/html/xen-devel/2012-08/msg00134.html
...
> >>> At the time I thought we also needed this patch, before yours:
> >>>   http://lists.xen.org/archives/html/xen-devel/2012-08/msg00870.html
> >>>
> >>> It looks from that thread like I was hoping for an ack from someone
> >>> else on my patch.
> >>>
> >>> These look like bugfixes to me.  George, are they OK for 4.3 ?
> >> Hrm, I'm not terribly happy about this kind of change this late in the
> >> day, but I think overall it's best to fix this.

Perhaps I don't understand the freeze policy.  I thought we were still
accepting bugfixes ?  I guess at some point we'll start accepting
fixes only for release-critical bugs, but surely not yet ?

> >> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> > This old mail is long gone from my INBOX, can I get either a resend or a
> > set of message ids which I can track down?
> >
> > Also can you both (Ian and George) clarify whether your acks apply to
> > Andrew's series (or single patch?) from last year or to Julien's patch
> > or to both.
> 
> Single patch, as far as this is concerned.

I meant exactly the two patches in these emails
 http://lists.xen.org/archives/html/xen-devel/2012-08/msg00870.html
 http://lists.xen.org/archives/html/xen-devel/2012-08/msg00134.html
in that order.

Ian.
George Dunlap May 8, 2013, 12:59 p.m. UTC | #8
On 08/05/13 13:51, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH] build: Conditional build/clean/distclean targets on subsystems"):
>> On 08/05/13 12:18, Ian Campbell wrote:
>>> On Wed, 2013-05-08 at 11:22 +0100, George Dunlap wrote:
>>>> On Tue, May 7, 2013 at 6:27 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>>>>> Andrew Cooper writes ("Re: [Xen-devel] [PATCH] build: Conditional build/clean/distclean targets on subsystems"):
>>>>>> I did attempt to fix this before with
>>>>>> http://lists.xen.org/archives/html/xen-devel/2012-08/msg00134.html
> ...
>>>>> At the time I thought we also needed this patch, before yours:
>>>>>    http://lists.xen.org/archives/html/xen-devel/2012-08/msg00870.html
>>>>>
>>>>> It looks from that thread like I was hoping for an ack from someone
>>>>> else on my patch.
>>>>>
>>>>> These look like bugfixes to me.  George, are they OK for 4.3 ?
>>>> Hrm, I'm not terribly happy about this kind of change this late in the
>>>> day, but I think overall it's best to fix this.
> Perhaps I don't understand the freeze policy.  I thought we were still
> accepting bugfixes ?  I guess at some point we'll start accepting
> fixes only for release-critical bugs, but surely not yet ?

I haven't been using a strict rule; I've been attempting to approach 
each request from a risk/benefits perspective.  In this case, the change 
doesn't look *terribly* risky; but it does seem like there may be a bit 
of risk, and overall the benefit didn't seem to be terribly large 
either.  On balance, in my judgement it comes pretty close to the line.  
It's quite possible I'm judging inaccurately in this case -- either 
overestimating the risk, or underestimating the benefit.  But it's 
probably better to have a discussion about that in a case where we 
actually disagree about the conclusion. :-)

  -George
Ian Campbell May 10, 2013, 2:02 p.m. UTC | #9
On Wed, 2013-05-08 at 13:14 +0100, Andrew Cooper wrote:
> On 08/05/13 12:18, Ian Campbell wrote:
> > On Wed, 2013-05-08 at 11:22 +0100, George Dunlap wrote:
> >> On Tue, May 7, 2013 at 6:27 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> >>> Andrew Cooper writes ("Re: [Xen-devel] [PATCH] build: Conditional build/clean/distclean targets on subsystems"):
> >>>> I did attempt to fix this before with
> >>>> http://lists.xen.org/archives/html/xen-devel/2012-08/msg00134.html
> >>>>
> >>>> Please allow this to constitute a "ping" regarding the patch on that email.
> >>> We had a little thread about this then.
> >>>
> >>> At the time I thought we also needed this patch, before yours:
> >>>   http://lists.xen.org/archives/html/xen-devel/2012-08/msg00870.html
> >>>
> >>> It looks from that thread like I was hoping for an ack from someone
> >>> else on my patch.
> >>>
> >>> These look like bugfixes to me.  George, are they OK for 4.3 ?
> >> Hrm, I'm not terribly happy about this kind of change this late in the
> >> day, but I think overall it's best to fix this.
> >>
> >> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> > This old mail is long gone from my INBOX, can I get either a resend or a
> > set of message ids which I can track down?
> >
> > Also can you both (Ian and George) clarify whether your acks apply to
> > Andrew's series (or single patch?) from last year or to Julien's patch
> > or to both.
> 
> Single patch, as far as this is concerned.

Are you planning to resend as requested? (or did I miss it?)

AIUI Ians c-stubdom patch is no longer needed since stubdom got
configure'd up.

Ian.
diff mbox

Patch

diff --git a/buildconfigs/mk.linux-2.6-common b/buildconfigs/common.linux-2.6
similarity index 100%
rename from buildconfigs/mk.linux-2.6-common
rename to buildconfigs/common.linux-2.6
diff --git a/buildconfigs/mk.linux-2.6 b/buildconfigs/mk.linux-2.6
index 6b8d989..6523afb 100644
--- a/buildconfigs/mk.linux-2.6
+++ b/buildconfigs/mk.linux-2.6
@@ -7,4 +7,4 @@  XEN_LINUX_CONFIG_UPDATE := buildconfigs/enable-xen-config
 
 EXTRAVERSION ?=
 
-include buildconfigs/mk.linux-2.6-common
+include buildconfigs/common.linux-2.6
diff --git a/buildconfigs/mk.linux-2.6-native b/buildconfigs/mk.linux-2.6-native
index c7c0949..6e2a77b 100644
--- a/buildconfigs/mk.linux-2.6-native
+++ b/buildconfigs/mk.linux-2.6-native
@@ -1,5 +1,7 @@ 
 EXTRAVERSION = -native
 IMAGE_TARGET = bzImage
 INSTALL_BOOT_PATH = $(DESTDIR)/boot
+LINUX_VER    ?= 2.6.18
+XEN_LINUX_SOURCE ?= hg-clone
 
-include buildconfigs/mk.linux-2.6-common
+include buildconfigs/common.linux-2.6
diff --git a/buildconfigs/mk.linux-2.6-pvops b/buildconfigs/mk.linux-2.6-pvops
index 59cae79..9a11c7d 100644
--- a/buildconfigs/mk.linux-2.6-pvops
+++ b/buildconfigs/mk.linux-2.6-pvops
@@ -14,4 +14,4 @@  XEN_LINUX_GIT_REMOTEBRANCH ?= xen/stable-2.6.32.x
 
 EXTRAVERSION ?=
 
-include buildconfigs/mk.linux-2.6-common
+include buildconfigs/common.linux-2.6
diff --git a/buildconfigs/mk.linux-2.6-tip-latest b/buildconfigs/mk.linux-2.6-tip-latest
index 2a0b9af..158dda0 100644
--- a/buildconfigs/mk.linux-2.6-tip-latest
+++ b/buildconfigs/mk.linux-2.6-tip-latest
@@ -14,4 +14,4 @@  XEN_LINUX_GIT_REMOTEBRANCH ?= auto-latest
 
 EXTRAVERSION ?=
 
-include buildconfigs/mk.linux-2.6-common
+include buildconfigs/common.linux-2.6
diff --git a/buildconfigs/mk.linux-2.6-xen b/buildconfigs/mk.linux-2.6-xen
index 8594b55..b1facb6 100644
--- a/buildconfigs/mk.linux-2.6-xen
+++ b/buildconfigs/mk.linux-2.6-xen
@@ -3,4 +3,4 @@  LINUX_VER    ?= 2.6.18
 
 XEN_LINUX_SOURCE ?= hg-clone
 
-include buildconfigs/mk.linux-2.6-common
+include buildconfigs/common.linux-2.6