Re: [Xen-devel] [PATCH] fix qemu building with older make

[Don Koch <dkoch@xxxxxxxxxxx>]

On Mon, 4 Aug 2014 15:54:52 +0100
George Dunlap <george.dunlap@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> wrote:
> >>>> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
> >>>>> On 29.07.14 at 15:57, <Ian.Jackson@xxxxxxxxxxxxx> 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.

In 3.10.51, XEN_DOM0 is "dev_bool y" and the MAX_INDIRECT_SEGMENTS et
al. macros are not defined (also not used). It would appear that the
3.10 used in CentOS7 is some combination of 3.10 and newer linux
versions.

-d

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel