From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] fix qemu building with older make Date: Mon, 4 Aug 2014 15:54:52 +0100 Message-ID: <53DF9EBC.7050608@eu.citrix.com> References: <53D6332002000078000267C3@mail.emea.novell.com> <21463.43107.996862.418550@mariner.uk.xensource.com> <53D7CA430200007800027501@mail.emea.novell.com> <21463.49467.652734.346861@mariner.uk.xensource.com> <53D7E4320200007800027623@mail.emea.novell.com> <1406712159.5934.11.camel@kazak.uk.xensource.com> <53DA2FD6.7090701@terremark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XEJf8-0003pk-LA for xen-devel@lists.xenproject.org; Mon, 04 Aug 2014 14:54:58 +0000 In-Reply-To: <53DA2FD6.7090701@terremark.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Don Slutz , Ian Campbell , Jan Beulich Cc: xen-devel , Keir Fraser , Ian Jackson , Tim Deegan List-Id: xen-devel@lists.xenproject.org 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, wrote: >>>> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"): >>>>> On 29.07.14 at 15:57, 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