From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] fix qemu building with older make Date: Mon, 1 Sep 2014 11:41:37 +0100 Message-ID: <54044D61.2000408@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> <53DF9EBC.7050608@eu.citrix.com> <20140811114209.bdb8b2498f0d921cd9efb7ea@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 1XOP3a-0001TP-QI for xen-devel@lists.xenproject.org; Mon, 01 Sep 2014 10:41:55 +0000 In-Reply-To: <20140811114209.bdb8b2498f0d921cd9efb7ea@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 Koch Cc: Keir Fraser , Tim Deegan , Ian Jackson , Don Slutz , Ian Campbell , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org On 08/11/2014 04:42 PM, Don Koch wrote: > On Mon, 4 Aug 2014 15:54:52 +0100 > George Dunlap 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, 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 > 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