FYI: The plan for Xen kernels in Fedora 9

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a friendly alert of the major plans we have for Xen kernels in 
Fedora 9 timeframe...

Since we first added Xen in Fedora Core 5, our kernels have been based on
a forward-port of XenSource's upstream Xen kernels, to new LKML. For a
long time we ported their 2.6.16 tree to 2.6.18. Now we do ports of their
2.6.18 tree to 2.6.21/22/23, etc.  At the same time, upstream Linux gained
Xen support for i386 DomU, and shortly x86_64  DomU, and is generally
getting ever more virtualization capabilities.

As everyone knows, we have tended to lag behind Fedora's state-of-the-art 
bare metal kernels by several releases due to the effort required to port
Xen to newer LKML releases. Despite our best efforts, this lag has been 
getting worse, not better.

We have taken the decision, that this situation is unacceptable for Fedora 9.
We simply cannot spend more time forward porting Xen kernels. Either Xen has
to be dropped entirely, or we need a different strategy for dealing with the
kernels. Since people seeem to use Xen, we have decided not to drop it :-)

So the plan is to re-focus 100% of all Xen kernel efforts onto paravirt_ops.
LKML already has i386 pv_ops + Xen DomU. We intend to build on this to
add:

  - x64_64 pv_ops
  - x86_64 Xen DomU on pv_ops
  - i386 & x86_64  Xen Dom0  on pv_ops
  - memory balloon
  - paravirt framebuffer
  - save/restore

All of this based on same LKML release as Fedora bare metal. If all goes to
plan it may even be in the base kernel RPM, instead of kernel-xen, but thats
a minor concern compared to the actual coding.

Getting all this done for Fedora 9 is seriously ambitious, but it is the only
long term sustainable option, other than dropping Xen entirely.

What this means though, is that Fedora 9 Xen will certainly be going through
periods of instability and will certainly be even buggier than normal. F9
may well end up lacking features compared to Xen in Fedora 8 & earlier (eg no
PCI device passthrough, or CPU hotplug). On the plus side though we will be
100% back in sync with bare metal kernel versions & hopefully even have a
lot of this stuff merged in LKML to make ongoing maintainence sustainable.
Short term pain; Long term gain!

I have not got any ETA on when any of these kernel changes will appear in
rawhide - some time before the F9 feature freeze date is best guesstimate.
We will alert people when the time comes. There is a F9 feature page
with some amount of info about the plan...

   http://fedoraproject.org/wiki/Features/XenPvops

In terms of Fedora 6/7/8 maintainence... The kernel-xen in these existing 
releases already lags behind the bare metal kernel version by 2-3 releases.
We do not intend to continue trying to rebase the kernel-xen in existing
Fedora releases. It will be essentially important bug-fix mode only. This
is neccessary to enable maximum resources to be focused on the critical
Fedora 9 Xen work.

Regards,
Dan ...on behalf of some very busy Fedora Xen kernel developers :-)
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

--
Fedora-xen mailing list
Fedora-xen@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-xen

[Index of Archives]     [Fedora General]     [Fedora Music]     [Linux Kernel]     [Fedora Desktop]     [Fedora Directory]     [PAM]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux