Hi Ho! I have been taking my time, reading all the responses and reflecting on them. 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. Regards, 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