[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] fix qemu building with older make
On 09/08/2014 03:10 PM, Don Koch wrote:
On Mon, 1 Sep 2014 11:41:37 +0100
George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
On 08/11/2014 04:42 PM, Don Koch wrote:
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.
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. :-)
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
