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

Re: Packaing Xen 3.0 etc for Debian

Hi Ho!

I have been taking my time, reading all the responses and reflecting on

We have to start with where the Xen project is currently at:

1) Xen is not yet part of the kernel, and the patches are rather
invasive, and hard to add to anything other than a vanilla kernel.org
tree, and are actually specific to a particular third level kernel.org
point release.  Later kernel versions require later Xen patch sets and
features, and possibly later Xen hypervisors, and vice versa.  This
should relax more as Xen matures and becomes integrated with the kernel
source itself.

2) Their stable release uses a kernel that is not patched for security
holes.  Fortunately, individual security fixes are almost all only small
patches that are easily merged with any kernel tree with the editing of
maybe 2 or 3 lines at worst.  This means that any kernel tree should be
easily maintainable, once the security fix patches are identified in the
kernel.org git change-sets.  

This identification process has to be done at the moment for the current
stable Debian kernel, so if the security fix patches where done by
individual CVE, and documented with the kernel versions they are needed
for, any Xen kernel tree should be easily maintainable separately.

3) Xen at some point plan to release a Xen stable based around a later
standard kernel than 2.6.12

My proposal:

It is obvious that the best way to include Xen into Debian at the moment
is to package the tools, hypervisor, and kernel as companion packages in
version lockstep from the same Xen community release, with separate
streams for stable and unstable.  They should be part of volatile (for
stable), and etch. 

Basing the kernel Xen kernel source on the Debian standard kernel tree
will probably make too much work for the kernel team currently.  With
the security fix patches available above, the Xen kernels can be kept up
to date with security, though they would not support the same amount of
hardware the standard Debian kernels do as they would be based on the
Xen patched kernel.org sources.  The Debian Xen team should be part of
the kernel team though to be officially able to receive/work with kernel
CVE that have not been publicly released yet.  Question: what about
embedded firmware in the kernel.org source?  I guess most issues with
unsupported hardware would be resolved that this is experimental, and is
primarily targeted at servers at the moment. 

Once the Xen kernel support becomes part of the official kernel.org
linux release, then Xen can be easily made part of unstable with the
tools, hypervisor and Xen built into the standard kernel tree. 

Guido, Ralph, Bastian and Steve, what do you think about the above?
With Ralph's work and the other work mentioned here, it sounds like the
software is almost there, apart from the organisational details.


Mathe Grant

On Fri, 2006-02-24 at 23:02 +1300, Matthew Grant wrote:
> Ralph,
> I am a Debian Maintainer who is seriously considering getting Xen into
> Debian and Ubuntu.
> I have been installing xen-unstable.hg from source on my AMD 64 and have
> been impressed with its relative stability.  
> I am prepared to sponsor your packages into Debian if we can get them
> cleaned up.  
> Other things I am looking at are special Xen source trees.  We would
> need the Debian security team to give us access to a patch repository
> for all the Linux security patches.  The trick is to get the security
> fixes split out from all the other updates that come in the point
> releases for the current vanila kernel.org tree. Patching Xen against
> the standard Debian kernel tree may be asking for problems, so it is
> better to work off a vanilla kernel.org tarball and xen-unstable.hg
> What are your thoughts?
> Regards,
> Matthew Grant
Matthew Grant <grantma@anathoth.gen.nz>
Matthew's UNIX Box

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: