[PATCH] fix qemu building with older make

[PATCH] fix qemu building with older make

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

The $(or ) builtin (uses introduced by commits ffbf089357 and
8962a8f951) is supported only from make 3.81 onwards, yet we claim to
only require make 3.80. Introduce a good enough fallback.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/Config.mk
+++ b/Config.mk
@@ -12,6 +12,7 @@ space   := $(empty) $(empty)
 
 # fallback for older make
 realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "$$PWD/$(notdir $(file))")))
+or       = $(if $(strip $(1)),$(1),$(if $(strip $(2)),$(2),$(if $(strip $(3)),$(3),$(if $(strip $(4)),$(4)))))
 
 -include $(XEN_ROOT)/.config
 
@@ -266,11 +267,11 @@ QEMU_TRADITIONAL_REVISION ?= d0395cc49b2
 # QEMU_UPSTREAM_LOC ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
 
 # Defaults for subtree locations
-QEMU_TRADITIONAL_LOC ?= $(or $(wildcard $(QEMU_TRADITIONAL_INTREE)),\
-                        $(QEMU_TRADITIONAL_URL))
-
-QEMU_UPSTREAM_LOC ?= $(or $(wildcard $(QEMU_UPSTREAM_INTREE)),\
-                        $(QEMU_UPSTREAM_URL))
+QEMU_TRADITIONAL_LOC ?= $(call or,$(wildcard $(QEMU_TRADITIONAL_INTREE)),\
+                                  $(QEMU_TRADITIONAL_URL))
+
+QEMU_UPSTREAM_LOC ?= $(call or,$(wildcard $(QEMU_UPSTREAM_INTREE)),\
+                               $(QEMU_UPSTREAM_URL))
 
 # Short answer -- do not enable this unless you know what you are
 # doing and are prepared for some pain.




[-- Attachment #2: make-or-fallback.patch --]
[-- Type: text/plain, Size: 1436 bytes --]

fix qemu building with older make

The $(or ) builtin (uses introduced by commits ffbf089357 and
8962a8f951) is supported only from make 3.81 onwards, yet we claim to
only require make 3.80. Introduce a good enough fallback.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/Config.mk
+++ b/Config.mk
@@ -12,6 +12,7 @@ space   := $(empty) $(empty)
 
 # fallback for older make
 realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "$$PWD/$(notdir $(file))")))
+or       = $(if $(strip $(1)),$(1),$(if $(strip $(2)),$(2),$(if $(strip $(3)),$(3),$(if $(strip $(4)),$(4)))))
 
 -include $(XEN_ROOT)/.config
 
@@ -266,11 +267,11 @@ QEMU_TRADITIONAL_REVISION ?= d0395cc49b2
 # QEMU_UPSTREAM_LOC ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
 
 # Defaults for subtree locations
-QEMU_TRADITIONAL_LOC ?= $(or $(wildcard $(QEMU_TRADITIONAL_INTREE)),\
-                        $(QEMU_TRADITIONAL_URL))
-
-QEMU_UPSTREAM_LOC ?= $(or $(wildcard $(QEMU_UPSTREAM_INTREE)),\
-                        $(QEMU_UPSTREAM_URL))
+QEMU_TRADITIONAL_LOC ?= $(call or,$(wildcard $(QEMU_TRADITIONAL_INTREE)),\
+                                  $(QEMU_TRADITIONAL_URL))
+
+QEMU_UPSTREAM_LOC ?= $(call or,$(wildcard $(QEMU_UPSTREAM_INTREE)),\
+                               $(QEMU_UPSTREAM_URL))
 
 # Short answer -- do not enable this unless you know what you are
 # doing and are prepared for some pain.

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Re: [PATCH] fix qemu building with older make

[George Dunlap]

On 07/28/2014 10:25 AM, Jan Beulich wrote:
> The $(or ) builtin (uses introduced by commits ffbf089357 and
> 8962a8f951) is supported only from make 3.81 onwards, yet we claim to
> only require make 3.80. Introduce a good enough fallback.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I don't really know enough about make to have an opinion on the code 
itself; but re the idea:

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

>
> --- a/Config.mk
> +++ b/Config.mk
> @@ -12,6 +12,7 @@ space   := $(empty) $(empty)
>
>   # fallback for older make
>   realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "$$PWD/$(notdir $(file))")))
> +or       = $(if $(strip $(1)),$(1),$(if $(strip $(2)),$(2),$(if $(strip $(3)),$(3),$(if $(strip $(4)),$(4)))))
>
>   -include $(XEN_ROOT)/.config
>
> @@ -266,11 +267,11 @@ QEMU_TRADITIONAL_REVISION ?= d0395cc49b2
>   # QEMU_UPSTREAM_LOC ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
>
>   # Defaults for subtree locations
> -QEMU_TRADITIONAL_LOC ?= $(or $(wildcard $(QEMU_TRADITIONAL_INTREE)),\
> -                        $(QEMU_TRADITIONAL_URL))
> -
> -QEMU_UPSTREAM_LOC ?= $(or $(wildcard $(QEMU_UPSTREAM_INTREE)),\
> -                        $(QEMU_UPSTREAM_URL))
> +QEMU_TRADITIONAL_LOC ?= $(call or,$(wildcard $(QEMU_TRADITIONAL_INTREE)),\
> +                                  $(QEMU_TRADITIONAL_URL))
> +
> +QEMU_UPSTREAM_LOC ?= $(call or,$(wildcard $(QEMU_UPSTREAM_INTREE)),\
> +                               $(QEMU_UPSTREAM_URL))
>
>   # Short answer -- do not enable this unless you know what you are
>   # doing and are prepared for some pain.
>
>
>

Re: [PATCH] fix qemu building with older make

[Ian Jackson]

Jan Beulich writes ("[PATCH] fix qemu building with older make"):
> The $(or ) builtin (uses introduced by commits ffbf089357 and
> 8962a8f951) is supported only from make 3.81 onwards, yet we claim to
> only require make 3.80. Introduce a good enough fallback.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/Config.mk
> +++ b/Config.mk
> @@ -12,6 +12,7 @@ space   := $(empty) $(empty)
>  
>  # fallback for older make
>  realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "$$PWD/$(notdir $(file))")))
> +or       = $(if $(strip $(1)),$(1),$(if $(strip $(2)),$(2),$(if $(strip $(3)),$(3),$(if $(strip $(4)),$(4)))))

Can we (a) have a comment here explaining why (b) have some kind of
time limit on how long we need to support make 3.80 ?

3.81 was released upstream over eight years ago in April 2006.

(AFAICT as far as Debian goes that means it has been in every Debian
release since etch, which was released in April 2007.)

Ian.

Re: [PATCH] fix qemu building with older make

[Jan Beulich]

>>> On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("[PATCH] fix qemu building with older make"):
>> The $(or ) builtin (uses introduced by commits ffbf089357 and
>> 8962a8f951) is supported only from make 3.81 onwards, yet we claim to
>> only require make 3.80. Introduce a good enough fallback.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> --- a/Config.mk
>> +++ b/Config.mk
>> @@ -12,6 +12,7 @@ space   := $(empty) $(empty)
>>  
>>  # fallback for older make
>>  realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "$$PWD/$(notdir $(file))")))
>> +or       = $(if $(strip $(1)),$(1),$(if $(strip $(2)),$(2),$(if $(strip $(3)),$(3),$(if $(strip $(4)),$(4)))))
> 
> Can we (a) have a comment here explaining why

To me the "fallback for older make" comment is enough of answering
the "why" part. What else do you want?

> (b) have some kind of
> time limit on how long we need to support make 3.80 ?
> 
> 3.81 was released upstream over eight years ago in April 2006.

I know, but I also know there's going to be a few more years where
for my day-to-day work SLE10 (coming with make 3.80) is the lowest
common denominator in order to be able to test backports there.
And RHEL5, iirc released at about the same time, was also quite
recently considered a platform desirable to continue to support.

Of course I'm having my own, self-built newer make versions around,
so as far as make is concerned I could live with that compatibility
requirement dropped (leaving aside that tying the resulting build
failure when inadvertently using the older make to the missing
support for a particular builtin isn't straightforward). But there are
other old package versions we still support (like Python 2.4) for that
same reason, and I can't see myself using self-built replacements of
all those as well.

Jan

Re: [PATCH] fix qemu building with older make

[Ian Jackson]

Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
> On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> wrote:
> >>  # fallback for older make
> >>  realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "$$PWD/$(notdir $(file))")))
> >> +or       = $(if $(strip $(1)),$(1),$(if $(strip $(2)),$(2),$(if $(strip $(3)),$(3),$(if $(strip $(4)),$(4)))))
> > 
> > Can we (a) have a comment here explaining why
> 
> To me the "fallback for older make" comment is enough of answering
> the "why" part. What else do you want?

Oh, I hadn't spotted that amongst the other noise.  I guess that will
do.

> > (b) have some kind of
> > time limit on how long we need to support make 3.80 ?
> > 
> > 3.81 was released upstream over eight years ago in April 2006.
> 
> I know, but I also know there's going to be a few more years where
> for my day-to-day work SLE10 (coming with make 3.80) is the lowest
> common denominator in order to be able to test backports there.
> And RHEL5, iirc released at about the same time, was also quite
> recently considered a platform desirable to continue to support.

RHEL5 was released in March 2007, 11 months after make 3.81 was
released upstream.  Furthermore it is seven years old.  SLES10 was
released in June 2006, and is therefore eight years old.  People refer
to Debian stable as `Debian stale' but frankly this is ridiculous.

At the very least can we put some kind of bound on this ?

How about we `compromise' on the following rule: we will feel
completely entitled to delete any build and tools compatibility code
for anything which was superseded upstream more than a decade ago.

Ian.

Re: [PATCH] fix qemu building with older make

[Jan Beulich]

>>> On 29.07.14 at 17:43, <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
>> On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> wrote:
>> > (b) have some kind of
>> > time limit on how long we need to support make 3.80 ?
>> > 
>> > 3.81 was released upstream over eight years ago in April 2006.
>> 
>> I know, but I also know there's going to be a few more years where
>> for my day-to-day work SLE10 (coming with make 3.80) is the lowest
>> common denominator in order to be able to test backports there.
>> And RHEL5, iirc released at about the same time, was also quite
>> recently considered a platform desirable to continue to support.
> 
> RHEL5 was released in March 2007, 11 months after make 3.81 was
> released upstream.  Furthermore it is seven years old.  SLES10 was
> released in June 2006, and is therefore eight years old.  People refer
> to Debian stable as `Debian stale' but frankly this is ridiculous.
> 
> At the very least can we put some kind of bound on this ?
> 
> How about we `compromise' on the following rule: we will feel
> completely entitled to delete any build and tools compatibility code
> for anything which was superseded upstream more than a decade ago.

I'm personally not in favor of this, but if a reasonably large majority
would want a rule like this, I'll have to try and live with it. My scope
for deprecation would be more towards such relatively wide spread
distros going completely out of service (i.e. in the case of SLES not
just general support [which happened about a year ago], but also
long-term/extended support [which I think is scheduled for like 12
or 13 years after general availability]).

Jan

Re: [PATCH] fix qemu building with older make

[George Dunlap]

On 07/29/2014 05:13 PM, Jan Beulich wrote:
>>>> On 29.07.14 at 17:43, <Ian.Jackson@eu.citrix.com> wrote:
>> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
>>> On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> wrote:
>>>> (b) have some kind of
>>>> time limit on how long we need to support make 3.80 ?
>>>>
>>>> 3.81 was released upstream over eight years ago in April 2006.
>>>
>>> I know, but I also know there's going to be a few more years where
>>> for my day-to-day work SLE10 (coming with make 3.80) is the lowest
>>> common denominator in order to be able to test backports there.
>>> And RHEL5, iirc released at about the same time, was also quite
>>> recently considered a platform desirable to continue to support.
>>
>> RHEL5 was released in March 2007, 11 months after make 3.81 was
>> released upstream.  Furthermore it is seven years old.  SLES10 was
>> released in June 2006, and is therefore eight years old.  People refer
>> to Debian stable as `Debian stale' but frankly this is ridiculous.
>>
>> At the very least can we put some kind of bound on this ?
>>
>> How about we `compromise' on the following rule: we will feel
>> completely entitled to delete any build and tools compatibility code
>> for anything which was superseded upstream more than a decade ago.
>
> I'm personally not in favor of this, but if a reasonably large majority
> would want a rule like this, I'll have to try and live with it. My scope
> for deprecation would be more towards such relatively wide spread
> distros going completely out of service (i.e. in the case of SLES not
> just general support [which happened about a year ago], but also
> long-term/extended support [which I think is scheduled for like 12
> or 13 years after general availability]).

FWIW, one of the things that has made Docker possible is Linus' quixotic 
commitment to binary compatibility for any user-space program, whether 
in a distro or not.

RHEL apparently has several lifecycle "phases" 
(https://access.redhat.com/support/policy/updates/errata/); "Production 
2" for RHEL 5 just ended in January of this year; "Production 3" won't 
end until 2017, and the "Extended Life Phase" won't end until 2020.

Staying compatible with major distros, particularly if it's something 
small (if slightly ugly) like this, seems like a small price to pay.

  -George

Re: [PATCH] fix qemu building with older make

[Andrew Cooper]

On 29/07/14 17:20, George Dunlap wrote:
> On 07/29/2014 05:13 PM, Jan Beulich wrote:
>>>>> On 29.07.14 at 17:43, <Ian.Jackson@eu.citrix.com> wrote:
>>> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
>>>> On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> wrote:
>>>>> (b) have some kind of
>>>>> time limit on how long we need to support make 3.80 ?
>>>>>
>>>>> 3.81 was released upstream over eight years ago in April 2006.
>>>>
>>>> I know, but I also know there's going to be a few more years where
>>>> for my day-to-day work SLE10 (coming with make 3.80) is the lowest
>>>> common denominator in order to be able to test backports there.
>>>> And RHEL5, iirc released at about the same time, was also quite
>>>> recently considered a platform desirable to continue to support.
>>>
>>> RHEL5 was released in March 2007, 11 months after make 3.81 was
>>> released upstream.  Furthermore it is seven years old.  SLES10 was
>>> released in June 2006, and is therefore eight years old.  People refer
>>> to Debian stable as `Debian stale' but frankly this is ridiculous.
>>>
>>> At the very least can we put some kind of bound on this ?
>>>
>>> How about we `compromise' on the following rule: we will feel
>>> completely entitled to delete any build and tools compatibility code
>>> for anything which was superseded upstream more than a decade ago.
>>
>> I'm personally not in favor of this, but if a reasonably large majority
>> would want a rule like this, I'll have to try and live with it. My scope
>> for deprecation would be more towards such relatively wide spread
>> distros going completely out of service (i.e. in the case of SLES not
>> just general support [which happened about a year ago], but also
>> long-term/extended support [which I think is scheduled for like 12
>> or 13 years after general availability]).
>
> FWIW, one of the things that has made Docker possible is Linus'
> quixotic commitment to binary compatibility for any user-space
> program, whether in a distro or not.
>
> RHEL apparently has several lifecycle "phases"
> (https://access.redhat.com/support/policy/updates/errata/);
> "Production 2" for RHEL 5 just ended in January of this year;
> "Production 3" won't end until 2017, and the "Extended Life Phase"
> won't end until 2020.
>
> Staying compatible with major distros, particularly if it's something
> small (if slightly ugly) like this, seems like a small price to pay.
>
>  -George

We should not aim to deliberately break things.  I would suggest a
slightly more lax approach; if the distro has a requisite version in a
standard package repository then we could consider breaking
compatibility with the older package version.

e.g. a newer version of make available in something like EPEL for RHEL5.

I have no knowledge of whether such things exist for SLES.

~Andrew

Re: [PATCH] fix qemu building with older make

[Ian Campbell]

On Tue, 2014-07-29 at 17:13 +0100, Jan Beulich wrote:
> >>> On 29.07.14 at 17:43, <Ian.Jackson@eu.citrix.com> wrote:
> > Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
> >> On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> wrote:
> >> > (b) have some kind of
> >> > time limit on how long we need to support make 3.80 ?
> >> > 
> >> > 3.81 was released upstream over eight years ago in April 2006.
> >> 
> >> I know, but I also know there's going to be a few more years where
> >> for my day-to-day work SLE10 (coming with make 3.80) is the lowest
> >> common denominator in order to be able to test backports there.
> >> And RHEL5, iirc released at about the same time, was also quite
> >> recently considered a platform desirable to continue to support.
> > 
> > RHEL5 was released in March 2007, 11 months after make 3.81 was
> > released upstream.  Furthermore it is seven years old.  SLES10 was
> > released in June 2006, and is therefore eight years old.  People refer
> > to Debian stable as `Debian stale' but frankly this is ridiculous.
> > 
> > At the very least can we put some kind of bound on this ?
> > 
> > How about we `compromise' on the following rule: we will feel
> > completely entitled to delete any build and tools compatibility code
> > for anything which was superseded upstream more than a decade ago.
> 
> I'm personally not in favor of this, but if a reasonably large majority
> would want a rule like this, I'll have to try and live with it. My scope
> for deprecation would be more towards such relatively wide spread
> distros going completely out of service (i.e. in the case of SLES not
> just general support [which happened about a year ago], but also
> long-term/extended support [which I think is scheduled for like 12
> or 13 years after general availability]).

(I've got a sense of Deja Vu, sorry if we've been through this
before...)

You aren't expected to support users installing Xen 4.5 onto SLE10
though, surely? After general support and into long term support even?.

For development purposes across multiple trees do chroot+bind mounts or
VMs not suffice?

I think our backstop for dependencies for the dom0 bits should be the
version of things where we might reasonably expect a new user to deploy
a new version of upstream Xen from scratch on. I find it hard to imagine
anyone doing that on Debian 6.0, SLE10 or RHEL5 these days rather than
choosing Debian 7.0, SLE11 or RHEL6.

Ian.

Re: [PATCH] fix qemu building with older make

[Jan Beulich]

>>> On 30.07.14 at 11:22, <Ian.Campbell@eu.citrix.com> wrote:
> You aren't expected to support users installing Xen 4.5 onto SLE10
> though, surely? After general support and into long term support even?.

No. I just like to do all development work centrally on one master
system, expecting to also test there.

> For development purposes across multiple trees do chroot+bind mounts or
> VMs not suffice?

I don't know if or how this could be leveraged. For none of the self
built components I use (binutils, gcc, Xen, kernel to name the most
important ones) I build packages; instead everything gets built using
plain make. Of course, for the hypervisor this would be fairly easy
to change, as there's no involved installation associated with it.
Which is, along with the option of just using a self-built make, why I
said I could probably live with the lowest common denominator tools
versions raised.

But as soon as it gets to building/using the tool stack, this would
change. And obviously I can't do much without that one, albeit the
main purpose of testing the hypervisor on as heterogeneous
hardware as possible would still be full-fillable to a certain degree
(i.e. at least boot testing would still be possible, and most other
stuff I do on systems with newer distro versions anyway).

Yet as we've seen with the various replies so far, there's no
uniform opinion one way or another anyway, and hence I would
think sticking to the currently documented tools versions is the
more compatible approach as long as no too involved workarounds
are needed to continue being able to use them.

Jan

Re: [PATCH] fix qemu building with older make

[Don Slutz]

On 07/30/14 05:22, Ian Campbell wrote:
> On Tue, 2014-07-29 at 17:13 +0100, Jan Beulich wrote:
>>>>> On 29.07.14 at 17:43, <Ian.Jackson@eu.citrix.com> wrote:
>>> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
>>>> On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> wrote:
>>>>> (b) have some kind of
>>>>> time limit on how long we need to support make 3.80 ?
>>>>>
>>>>> 3.81 was released upstream over eight years ago in April 2006.
>>>> I know, but I also know there's going to be a few more years where
>>>> for my day-to-day work SLE10 (coming with make 3.80) is the lowest
>>>> common denominator in order to be able to test backports there.
>>>> And RHEL5, iirc released at about the same time, was also quite
>>>> recently considered a platform desirable to continue to support.
>>> RHEL5 was released in March 2007, 11 months after make 3.81 was
>>> released upstream.  Furthermore it is seven years old.  SLES10 was
>>> released in June 2006, and is therefore eight years old.  People refer
>>> to Debian stable as `Debian stale' but frankly this is ridiculous.
>>>
>>> At the very least can we put some kind of bound on this ?
>>>
>>> How about we `compromise' on the following rule: we will feel
>>> completely entitled to delete any build and tools compatibility code
>>> for anything which was superseded upstream more than a decade ago.
>> I'm personally not in favor of this, but if a reasonably large majority
>> would want a rule like this, I'll have to try and live with it. My scope
>> for deprecation would be more towards such relatively wide spread
>> distros going completely out of service (i.e. in the case of SLES not
>> just general support [which happened about a year ago], but also
>> long-term/extended support [which I think is scheduled for like 12
>> or 13 years after general availability]).
> (I've got a sense of Deja Vu, sorry if we've been through this
> before...)
>
> You aren't expected to support users installing Xen 4.5 onto SLE10
> though, surely? After general support and into long term support even?.
>
> For development purposes across multiple trees do chroot+bind mounts or
> VMs not suffice?
>
> I think our backstop for dependencies for the dom0 bits should be the
> version of things where we might reasonably expect a new user to deploy
> a new version of upstream Xen from scratch on. I find it hard to imagine
> anyone doing that on Debian 6.0, SLE10 or RHEL5 these days rather than
> choosing Debian 7.0, SLE11 or RHEL6.

RHEL6 is not directly usable as Dom0 for xen.  You have to add a different
kernel and so is more complex.  So to use only disto stuff you were limited
to RHEL5 :(. However RHEL7 should be usable without extra work (I have yet
to verify this is true, do to limited time).

    -Don Slutz

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

Re: [PATCH] fix qemu building with older make

[George Dunlap]

On 07/31/2014 01:00 PM, Don Slutz wrote:
>
> On 07/30/14 05:22, Ian Campbell wrote:
>> On Tue, 2014-07-29 at 17:13 +0100, Jan Beulich wrote:
>>>>>> On 29.07.14 at 17:43, <Ian.Jackson@eu.citrix.com> wrote:
>>>> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
>>>>> On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> wrote:
>>>>>> (b) have some kind of
>>>>>> time limit on how long we need to support make 3.80 ?
>>>>>>
>>>>>> 3.81 was released upstream over eight years ago in April 2006.
>>>>> I know, but I also know there's going to be a few more years where
>>>>> for my day-to-day work SLE10 (coming with make 3.80) is the lowest
>>>>> common denominator in order to be able to test backports there.
>>>>> And RHEL5, iirc released at about the same time, was also quite
>>>>> recently considered a platform desirable to continue to support.
>>>> RHEL5 was released in March 2007, 11 months after make 3.81 was
>>>> released upstream.  Furthermore it is seven years old.  SLES10 was
>>>> released in June 2006, and is therefore eight years old.  People refer
>>>> to Debian stable as `Debian stale' but frankly this is ridiculous.
>>>>
>>>> At the very least can we put some kind of bound on this ?
>>>>
>>>> How about we `compromise' on the following rule: we will feel
>>>> completely entitled to delete any build and tools compatibility code
>>>> for anything which was superseded upstream more than a decade ago.
>>> I'm personally not in favor of this, but if a reasonably large majority
>>> would want a rule like this, I'll have to try and live with it. My scope
>>> for deprecation would be more towards such relatively wide spread
>>> distros going completely out of service (i.e. in the case of SLES not
>>> just general support [which happened about a year ago], but also
>>> long-term/extended support [which I think is scheduled for like 12
>>> or 13 years after general availability]).
>> (I've got a sense of Deja Vu, sorry if we've been through this
>> before...)
>>
>> You aren't expected to support users installing Xen 4.5 onto SLE10
>> though, surely? After general support and into long term support even?.
>>
>> For development purposes across multiple trees do chroot+bind mounts or
>> VMs not suffice?
>>
>> I think our backstop for dependencies for the dom0 bits should be the
>> version of things where we might reasonably expect a new user to deploy
>> a new version of upstream Xen from scratch on. I find it hard to imagine
>> anyone doing that on Debian 6.0, SLE10 or RHEL5 these days rather than
>> choosing Debian 7.0, SLE11 or RHEL6.
>
> RHEL6 is not directly usable as Dom0 for xen.  You have to add a different
> kernel and so is more complex.  So to use only disto stuff you were limited
> to RHEL5 :(. However RHEL7 should be usable without extra work (I have yet
> to verify this is true, do to limited time).

Eh?  It was my understanding that in RHEL7 they'd taken out *all* the 
pvops stuff, even what is required for the RHEL7 kernel to run as a 
plain PV domU, much less what is required for dom0.  (It still has the 
stuff necessary for PVHVM mode, AFAIK.)

  -George

Re: [PATCH] fix qemu building with older make

[Don Koch]

On Mon, 4 Aug 2014 15:54:52 +0100
George Dunlap <george.dunlap@eu.citrix.com> wrote:

> On 07/31/2014 01:00 PM, Don Slutz wrote:
> >
> > On 07/30/14 05:22, Ian Campbell wrote:
> >> On Tue, 2014-07-29 at 17:13 +0100, Jan Beulich wrote:
> >>>>>> On 29.07.14 at 17:43, <Ian.Jackson@eu.citrix.com> wrote:
> >>>> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
> >>>>> On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> wrote:
> >>>>>> (b) have some kind of
> >>>>>> time limit on how long we need to support make 3.80 ?
> >>>>>>
> >>>>>> 3.81 was released upstream over eight years ago in April 2006.
> >>>>> I know, but I also know there's going to be a few more years where
> >>>>> for my day-to-day work SLE10 (coming with make 3.80) is the lowest
> >>>>> common denominator in order to be able to test backports there.
> >>>>> And RHEL5, iirc released at about the same time, was also quite
> >>>>> recently considered a platform desirable to continue to support.
> >>>> RHEL5 was released in March 2007, 11 months after make 3.81 was
> >>>> released upstream.  Furthermore it is seven years old.  SLES10 was
> >>>> released in June 2006, and is therefore eight years old.  People refer
> >>>> to Debian stable as `Debian stale' but frankly this is ridiculous.
> >>>>
> >>>> At the very least can we put some kind of bound on this ?
> >>>>
> >>>> How about we `compromise' on the following rule: we will feel
> >>>> completely entitled to delete any build and tools compatibility code
> >>>> for anything which was superseded upstream more than a decade ago.
> >>> I'm personally not in favor of this, but if a reasonably large majority
> >>> would want a rule like this, I'll have to try and live with it. My scope
> >>> for deprecation would be more towards such relatively wide spread
> >>> distros going completely out of service (i.e. in the case of SLES not
> >>> just general support [which happened about a year ago], but also
> >>> long-term/extended support [which I think is scheduled for like 12
> >>> or 13 years after general availability]).
> >> (I've got a sense of Deja Vu, sorry if we've been through this
> >> before...)
> >>
> >> You aren't expected to support users installing Xen 4.5 onto SLE10
> >> though, surely? After general support and into long term support even?.
> >>
> >> For development purposes across multiple trees do chroot+bind mounts or
> >> VMs not suffice?
> >>
> >> I think our backstop for dependencies for the dom0 bits should be the
> >> version of things where we might reasonably expect a new user to deploy
> >> a new version of upstream Xen from scratch on. I find it hard to imagine
> >> anyone doing that on Debian 6.0, SLE10 or RHEL5 these days rather than
> >> choosing Debian 7.0, SLE11 or RHEL6.
> >
> > RHEL6 is not directly usable as Dom0 for xen.  You have to add a different
> > kernel and so is more complex.  So to use only disto stuff you were limited
> > to RHEL5 :(. However RHEL7 should be usable without extra work (I have yet
> > to verify this is true, do to limited time).
> 
> Eh?  It was my understanding that in RHEL7 they'd taken out *all* the 
> pvops stuff, even what is required for the RHEL7 kernel to run as a 
> plain PV domU, much less what is required for dom0.  (It still has the 
> stuff necessary for PVHVM mode, AFAIK.)
> 
>   -George

I was able to boot CentOS7 as dom0, but not until I had a) un-hardwired
XEN_DOM0 to being false (def_bool n) in the xen/Kconfig file and b) put
in the defines (swiped from 3.15) for MAX_INDIRECT_SEGMENTS et al in the
xen-blkback/common.h file. I was able to bring up a VM, too, but
haven't done extensive testing.

In 3.10.51, XEN_DOM0 is "dev_bool y" and the MAX_INDIRECT_SEGMENTS et
al. macros are not defined (also not used). It would appear that the
3.10 used in CentOS7 is some combination of 3.10 and newer linux
versions.

-d

Re: [PATCH] fix qemu building with older make

[George Dunlap]

On 08/11/2014 04:42 PM, Don Koch wrote:
> On Mon, 4 Aug 2014 15:54:52 +0100
> George Dunlap <george.dunlap@eu.citrix.com> wrote:
>
>> On 07/31/2014 01:00 PM, Don Slutz wrote:
>>> On 07/30/14 05:22, Ian Campbell wrote:
>>>> On Tue, 2014-07-29 at 17:13 +0100, Jan Beulich wrote:
>>>>>>>> On 29.07.14 at 17:43, <Ian.Jackson@eu.citrix.com> wrote:
>>>>>> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
>>>>>>> On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> wrote:
>>>>>>>> (b) have some kind of
>>>>>>>> time limit on how long we need to support make 3.80 ?
>>>>>>>>
>>>>>>>> 3.81 was released upstream over eight years ago in April 2006.
>>>>>>> I know, but I also know there's going to be a few more years where
>>>>>>> for my day-to-day work SLE10 (coming with make 3.80) is the lowest
>>>>>>> common denominator in order to be able to test backports there.
>>>>>>> And RHEL5, iirc released at about the same time, was also quite
>>>>>>> recently considered a platform desirable to continue to support.
>>>>>> RHEL5 was released in March 2007, 11 months after make 3.81 was
>>>>>> released upstream.  Furthermore it is seven years old.  SLES10 was
>>>>>> released in June 2006, and is therefore eight years old.  People refer
>>>>>> to Debian stable as `Debian stale' but frankly this is ridiculous.
>>>>>>
>>>>>> At the very least can we put some kind of bound on this ?
>>>>>>
>>>>>> How about we `compromise' on the following rule: we will feel
>>>>>> completely entitled to delete any build and tools compatibility code
>>>>>> for anything which was superseded upstream more than a decade ago.
>>>>> I'm personally not in favor of this, but if a reasonably large majority
>>>>> would want a rule like this, I'll have to try and live with it. My scope
>>>>> for deprecation would be more towards such relatively wide spread
>>>>> distros going completely out of service (i.e. in the case of SLES not
>>>>> just general support [which happened about a year ago], but also
>>>>> long-term/extended support [which I think is scheduled for like 12
>>>>> or 13 years after general availability]).
>>>> (I've got a sense of Deja Vu, sorry if we've been through this
>>>> before...)
>>>>
>>>> You aren't expected to support users installing Xen 4.5 onto SLE10
>>>> though, surely? After general support and into long term support even?.
>>>>
>>>> For development purposes across multiple trees do chroot+bind mounts or
>>>> VMs not suffice?
>>>>
>>>> I think our backstop for dependencies for the dom0 bits should be the
>>>> version of things where we might reasonably expect a new user to deploy
>>>> a new version of upstream Xen from scratch on. I find it hard to imagine
>>>> anyone doing that on Debian 6.0, SLE10 or RHEL5 these days rather than
>>>> choosing Debian 7.0, SLE11 or RHEL6.
>>> RHEL6 is not directly usable as Dom0 for xen.  You have to add a different
>>> kernel and so is more complex.  So to use only disto stuff you were limited
>>> to RHEL5 :(. However RHEL7 should be usable without extra work (I have yet
>>> to verify this is true, do to limited time).
>> Eh?  It was my understanding that in RHEL7 they'd taken out *all* the
>> pvops stuff, even what is required for the RHEL7 kernel to run as a
>> plain PV domU, much less what is required for dom0.  (It still has the
>> stuff necessary for PVHVM mode, AFAIK.)
>>
>>    -George
> I was able to boot CentOS7 as dom0, but not until I had a) un-hardwired
> XEN_DOM0 to being false (def_bool n) in the xen/Kconfig file and b) put
> in the defines (swiped from 3.15) for MAX_INDIRECT_SEGMENTS et al in the
> xen-blkback/common.h file. I was able to bring up a VM, too, but
> haven't done extensive testing.

Ah, interesting.  Still, although it happens to work now, it's not 
really a tested target, so it's probably not a good idea for anyone to 
rely on it continuing to work in the future.

  -George

Re: [PATCH] fix qemu building with older make

[Don Koch]

On Mon, 1 Sep 2014 11:41:37 +0100
George Dunlap <george.dunlap@eu.citrix.com> wrote:

> On 08/11/2014 04:42 PM, Don Koch wrote:
> > On Mon, 4 Aug 2014 15:54:52 +0100
> > George Dunlap <george.dunlap@eu.citrix.com> wrote:
> >
> >> On 07/31/2014 01:00 PM, Don Slutz wrote:
> >>> On 07/30/14 05:22, Ian Campbell wrote:
> >>>> On Tue, 2014-07-29 at 17:13 +0100, Jan Beulich wrote:
> >>>>>>>> On 29.07.14 at 17:43, <Ian.Jackson@eu.citrix.com> wrote:
> >>>>>> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
> >>>>>>> On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> wrote:
> >>>>>>>> (b) have some kind of
> >>>>>>>> time limit on how long we need to support make 3.80 ?
> >>>>>>>>
> >>>>>>>> 3.81 was released upstream over eight years ago in April 2006.
> >>>>>>> I know, but I also know there's going to be a few more years where
> >>>>>>> for my day-to-day work SLE10 (coming with make 3.80) is the lowest
> >>>>>>> common denominator in order to be able to test backports there.
> >>>>>>> And RHEL5, iirc released at about the same time, was also quite
> >>>>>>> recently considered a platform desirable to continue to support.
> >>>>>> RHEL5 was released in March 2007, 11 months after make 3.81 was
> >>>>>> released upstream.  Furthermore it is seven years old.  SLES10 was
> >>>>>> released in June 2006, and is therefore eight years old.  People refer
> >>>>>> to Debian stable as `Debian stale' but frankly this is ridiculous.
> >>>>>>
> >>>>>> At the very least can we put some kind of bound on this ?
> >>>>>>
> >>>>>> How about we `compromise' on the following rule: we will feel
> >>>>>> completely entitled to delete any build and tools compatibility code
> >>>>>> for anything which was superseded upstream more than a decade ago.
> >>>>> I'm personally not in favor of this, but if a reasonably large majority
> >>>>> would want a rule like this, I'll have to try and live with it. My scope
> >>>>> for deprecation would be more towards such relatively wide spread
> >>>>> distros going completely out of service (i.e. in the case of SLES not
> >>>>> just general support [which happened about a year ago], but also
> >>>>> long-term/extended support [which I think is scheduled for like 12
> >>>>> or 13 years after general availability]).
> >>>> (I've got a sense of Deja Vu, sorry if we've been through this
> >>>> before...)
> >>>>
> >>>> You aren't expected to support users installing Xen 4.5 onto SLE10
> >>>> though, surely? After general support and into long term support even?.
> >>>>
> >>>> For development purposes across multiple trees do chroot+bind mounts or
> >>>> VMs not suffice?
> >>>>
> >>>> I think our backstop for dependencies for the dom0 bits should be the
> >>>> version of things where we might reasonably expect a new user to deploy
> >>>> a new version of upstream Xen from scratch on. I find it hard to imagine
> >>>> anyone doing that on Debian 6.0, SLE10 or RHEL5 these days rather than
> >>>> choosing Debian 7.0, SLE11 or RHEL6.
> >>> RHEL6 is not directly usable as Dom0 for xen.  You have to add a different
> >>> kernel and so is more complex.  So to use only disto stuff you were limited
> >>> to RHEL5 :(. However RHEL7 should be usable without extra work (I have yet
> >>> to verify this is true, do to limited time).
> >> Eh?  It was my understanding that in RHEL7 they'd taken out *all* the
> >> pvops stuff, even what is required for the RHEL7 kernel to run as a
> >> plain PV domU, much less what is required for dom0.  (It still has the
> >> stuff necessary for PVHVM mode, AFAIK.)
> >>
> >>    -George
> > I was able to boot CentOS7 as dom0, but not until I had a) un-hardwired
> > XEN_DOM0 to being false (def_bool n) in the xen/Kconfig file and b) put
> > in the defines (swiped from 3.15) for MAX_INDIRECT_SEGMENTS et al in the
> > xen-blkback/common.h file. I was able to bring up a VM, too, but
> > haven't done extensive testing.
> 
> Ah, interesting.  Still, although it happens to work now, it's not 
> really a tested target, so it's probably not a good idea for anyone to 
> rely on it continuing to work in the future.

Agreed, especially since CentOS closed my bug report (with patches)
stating "will not fix since RHEL doesn't support it."

It looks like they don't have Xen4CentOS support for CentOS 7, at least, yet.

>   -George

-d

Re: [PATCH] fix qemu building with older make

[George Dunlap]

On 09/08/2014 03:10 PM, Don Koch wrote:
> On Mon, 1 Sep 2014 11:41:37 +0100
> George Dunlap <george.dunlap@eu.citrix.com> wrote:
>
>> On 08/11/2014 04:42 PM, Don Koch wrote:
>>> On Mon, 4 Aug 2014 15:54:52 +0100
>>> George Dunlap <george.dunlap@eu.citrix.com> wrote:
>>>
>>>> On 07/31/2014 01:00 PM, Don Slutz wrote:
>>>>> On 07/30/14 05:22, Ian Campbell wrote:
>>>>>> On Tue, 2014-07-29 at 17:13 +0100, Jan Beulich wrote:
>>>>>>>>>> On 29.07.14 at 17:43, <Ian.Jackson@eu.citrix.com> wrote:
>>>>>>>> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
>>>>>>>>> On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> wrote:
>>>>>>>>>> (b) have some kind of
>>>>>>>>>> time limit on how long we need to support make 3.80 ?
>>>>>>>>>>
>>>>>>>>>> 3.81 was released upstream over eight years ago in April 2006.
>>>>>>>>> I know, but I also know there's going to be a few more years where
>>>>>>>>> for my day-to-day work SLE10 (coming with make 3.80) is the lowest
>>>>>>>>> common denominator in order to be able to test backports there.
>>>>>>>>> And RHEL5, iirc released at about the same time, was also quite
>>>>>>>>> recently considered a platform desirable to continue to support.
>>>>>>>> RHEL5 was released in March 2007, 11 months after make 3.81 was
>>>>>>>> released upstream.  Furthermore it is seven years old.  SLES10 was
>>>>>>>> released in June 2006, and is therefore eight years old.  People refer
>>>>>>>> to Debian stable as `Debian stale' but frankly this is ridiculous.
>>>>>>>>
>>>>>>>> At the very least can we put some kind of bound on this ?
>>>>>>>>
>>>>>>>> How about we `compromise' on the following rule: we will feel
>>>>>>>> completely entitled to delete any build and tools compatibility code
>>>>>>>> for anything which was superseded upstream more than a decade ago.
>>>>>>> I'm personally not in favor of this, but if a reasonably large majority
>>>>>>> would want a rule like this, I'll have to try and live with it. My scope
>>>>>>> for deprecation would be more towards such relatively wide spread
>>>>>>> distros going completely out of service (i.e. in the case of SLES not
>>>>>>> just general support [which happened about a year ago], but also
>>>>>>> long-term/extended support [which I think is scheduled for like 12
>>>>>>> or 13 years after general availability]).
>>>>>> (I've got a sense of Deja Vu, sorry if we've been through this
>>>>>> before...)
>>>>>>
>>>>>> You aren't expected to support users installing Xen 4.5 onto SLE10
>>>>>> though, surely? After general support and into long term support even?.
>>>>>>
>>>>>> For development purposes across multiple trees do chroot+bind mounts or
>>>>>> VMs not suffice?
>>>>>>
>>>>>> I think our backstop for dependencies for the dom0 bits should be the
>>>>>> version of things where we might reasonably expect a new user to deploy
>>>>>> a new version of upstream Xen from scratch on. I find it hard to imagine
>>>>>> anyone doing that on Debian 6.0, SLE10 or RHEL5 these days rather than
>>>>>> choosing Debian 7.0, SLE11 or RHEL6.
>>>>> RHEL6 is not directly usable as Dom0 for xen.  You have to add a different
>>>>> kernel and so is more complex.  So to use only disto stuff you were limited
>>>>> to RHEL5 :(. However RHEL7 should be usable without extra work (I have yet
>>>>> to verify this is true, do to limited time).
>>>> Eh?  It was my understanding that in RHEL7 they'd taken out *all* the
>>>> pvops stuff, even what is required for the RHEL7 kernel to run as a
>>>> plain PV domU, much less what is required for dom0.  (It still has the
>>>> stuff necessary for PVHVM mode, AFAIK.)
>>>>
>>>>     -George
>>> I was able to boot CentOS7 as dom0, but not until I had a) un-hardwired
>>> XEN_DOM0 to being false (def_bool n) in the xen/Kconfig file and b) put
>>> in the defines (swiped from 3.15) for MAX_INDIRECT_SEGMENTS et al in the
>>> xen-blkback/common.h file. I was able to bring up a VM, too, but
>>> haven't done extensive testing.
>> Ah, interesting.  Still, although it happens to work now, it's not
>> really a tested target, so it's probably not a good idea for anyone to
>> rely on it continuing to work in the future.
> Agreed, especially since CentOS closed my bug report (with patches)
> stating "will not fix since RHEL doesn't support it."
>
> It looks like they don't have Xen4CentOS support for CentOS 7, at least, yet.

Well, it's mainly me that's working on it -- I just got access to the 
community build system last week.  Hopefully we should have that up 
within the next few weeks. :-)

  -George

Re: [PATCH] fix qemu building with older make

[Don Koch]

On Mon, 8 Sep 2014 15:12:05 +0100
George Dunlap <george.dunlap@eu.citrix.com> wrote:

> On 09/08/2014 03:10 PM, Don Koch wrote:

> > Agreed, especially since CentOS closed my bug report (with patches)
> > stating "will not fix since RHEL doesn't support it."
> >
> > It looks like they don't have Xen4CentOS support for CentOS 7, at least, yet.
> 
> Well, it's mainly me that's working on it -- I just got access to the 
> community build system last week.  Hopefully we should have that up 
> within the next few weeks. :-)

Cool. Let me know if you need help, testing or whatever. FWIW, CentOS
bug 0007571 has my patches.

-d

Re: [PATCH] fix qemu building with older make

[Pasi Kärkkäinen]

On Mon, Sep 08, 2014 at 03:12:05PM +0100, George Dunlap wrote:
> On 09/08/2014 03:10 PM, Don Koch wrote:
> >On Mon, 1 Sep 2014 11:41:37 +0100
> >George Dunlap <george.dunlap@eu.citrix.com> wrote:
> >
> >>On 08/11/2014 04:42 PM, Don Koch wrote:
> >>>On Mon, 4 Aug 2014 15:54:52 +0100
> >>>George Dunlap <george.dunlap@eu.citrix.com> wrote:
> >>>
> >>>>On 07/31/2014 01:00 PM, Don Slutz wrote:
> >>>>>On 07/30/14 05:22, Ian Campbell wrote:
> >>>>>>On Tue, 2014-07-29 at 17:13 +0100, Jan Beulich wrote:
> >>>>>>>>>>On 29.07.14 at 17:43, <Ian.Jackson@eu.citrix.com> wrote:
> >>>>>>>>Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
> >>>>>>>>>On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> wrote:
> >>>>>>>>>>(b) have some kind of
> >>>>>>>>>>time limit on how long we need to support make 3.80 ?
> >>>>>>>>>>
> >>>>>>>>>>3.81 was released upstream over eight years ago in April 2006.
> >>>>>>>>>I know, but I also know there's going to be a few more years where
> >>>>>>>>>for my day-to-day work SLE10 (coming with make 3.80) is the lowest
> >>>>>>>>>common denominator in order to be able to test backports there.
> >>>>>>>>>And RHEL5, iirc released at about the same time, was also quite
> >>>>>>>>>recently considered a platform desirable to continue to support.
> >>>>>>>>RHEL5 was released in March 2007, 11 months after make 3.81 was
> >>>>>>>>released upstream.  Furthermore it is seven years old.  SLES10 was
> >>>>>>>>released in June 2006, and is therefore eight years old.  People refer
> >>>>>>>>to Debian stable as `Debian stale' but frankly this is ridiculous.
> >>>>>>>>
> >>>>>>>>At the very least can we put some kind of bound on this ?
> >>>>>>>>
> >>>>>>>>How about we `compromise' on the following rule: we will feel
> >>>>>>>>completely entitled to delete any build and tools compatibility code
> >>>>>>>>for anything which was superseded upstream more than a decade ago.
> >>>>>>>I'm personally not in favor of this, but if a reasonably large majority
> >>>>>>>would want a rule like this, I'll have to try and live with it. My scope
> >>>>>>>for deprecation would be more towards such relatively wide spread
> >>>>>>>distros going completely out of service (i.e. in the case of SLES not
> >>>>>>>just general support [which happened about a year ago], but also
> >>>>>>>long-term/extended support [which I think is scheduled for like 12
> >>>>>>>or 13 years after general availability]).
> >>>>>>(I've got a sense of Deja Vu, sorry if we've been through this
> >>>>>>before...)
> >>>>>>
> >>>>>>You aren't expected to support users installing Xen 4.5 onto SLE10
> >>>>>>though, surely? After general support and into long term support even?.
> >>>>>>
> >>>>>>For development purposes across multiple trees do chroot+bind mounts or
> >>>>>>VMs not suffice?
> >>>>>>
> >>>>>>I think our backstop for dependencies for the dom0 bits should be the
> >>>>>>version of things where we might reasonably expect a new user to deploy
> >>>>>>a new version of upstream Xen from scratch on. I find it hard to imagine
> >>>>>>anyone doing that on Debian 6.0, SLE10 or RHEL5 these days rather than
> >>>>>>choosing Debian 7.0, SLE11 or RHEL6.
> >>>>>RHEL6 is not directly usable as Dom0 for xen.  You have to add a different
> >>>>>kernel and so is more complex.  So to use only disto stuff you were limited
> >>>>>to RHEL5 :(. However RHEL7 should be usable without extra work (I have yet
> >>>>>to verify this is true, do to limited time).
> >>>>Eh?  It was my understanding that in RHEL7 they'd taken out *all* the
> >>>>pvops stuff, even what is required for the RHEL7 kernel to run as a
> >>>>plain PV domU, much less what is required for dom0.  (It still has the
> >>>>stuff necessary for PVHVM mode, AFAIK.)
> >>>>
> >>>>    -George
> >>>I was able to boot CentOS7 as dom0, but not until I had a) un-hardwired
> >>>XEN_DOM0 to being false (def_bool n) in the xen/Kconfig file and b) put
> >>>in the defines (swiped from 3.15) for MAX_INDIRECT_SEGMENTS et al in the
> >>>xen-blkback/common.h file. I was able to bring up a VM, too, but
> >>>haven't done extensive testing.
> >>Ah, interesting.  Still, although it happens to work now, it's not
> >>really a tested target, so it's probably not a good idea for anyone to
> >>rely on it continuing to work in the future.
> >Agreed, especially since CentOS closed my bug report (with patches)
> >stating "will not fix since RHEL doesn't support it."
> >
> >It looks like they don't have Xen4CentOS support for CentOS 7, at least, yet.
> 
> Well, it's mainly me that's working on it -- I just got access to
> the community build system last week.  Hopefully we should have that
> up within the next few weeks. :-)
>

I already replied on another thread aswell, but here goes again,
it might interest some people. 

I added CC to a guy who has already fixed .spec file for Xen 4.4 on el7.
His website with .spec file and src.rpms is here: http://www.tlviewer.org/xen/cent7/dom0/ 


>  -George
> 


-- Pasi

Re: [PATCH] fix qemu building with older make

[Ian Jackson]

Jan Beulich writes ("[PATCH] fix qemu building with older make"):
> The $(or ) builtin (uses introduced by commits ffbf089357 and
> 8962a8f951) is supported only from make 3.81 onwards, yet we claim to
> only require make 3.80. Introduce a good enough fallback.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>