Re: [PATCH] fix qemu building with older make

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

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