Re: [PATCH] fix qemu building with older make

["Pasi Kärkkäinen" <pasik@iki.fi>]

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