Re: [PATCH] fix qemu building with older make

[George Dunlap <george.dunlap@eu.citrix.com>]

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