Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 05:34:44PM -0800, Steve Langasek wrote:
> > Yeah, it's a sort of kernel, but it's not the linux kernel... And it seems the
> > kernel team is about the linux kernel, not just any kernel, isn't it?
> The dom0 kernel is a Linux kernel built for the Xen hypervisor target. If
> Debian is to provide a complete packaged environment for Xen, which is
> certainly the goal I'm interested in (and Bastian as well, by the looks of
> it), that means packaging (at least) a dom0 kernel; and the only way to do
> that which would make the cut for stable is if it's kept synchronized with
> the main linux-2.6 package. I think the only reasonable way to do that is
> within the kernel team, which means people interested in helping with this
> part should consider joining the kernel team.
Yes, we absolutely agree about this! We also would have liked for the patch to
be integrated in the kernel team's work and from the xen kernel to be built and
maintained by the kernel team (of course we hadn't contacted them yet, so we
didn't know before if they were interested or if that would have been possible,
so it's great to know that such intrest exists!). Of course I agree that anyone
interested in Linux+Xen kernel work should join the kernel team!
> For the userspace tools and the hypervisor, clearly there's no reason why
> these need to be part of the kernel team repo as long as they aren't going
> to be part of the same linux-2.6 source package. As Bastian points out,
> though, there does still need to be close coordination between the
> hypervisor/userspace tools and the XenoLinux build, because we don't yet
> have mix-and-match compatibility.
I absolutely agree... That's why I'm kindly asking Bastian to join us and to be
on both teams, so he and other people interested in doing both can act as a
> My feeling is that it still makes sense to maintain the hypervisor and
> userspace tools in a separate pkg-xen group, and just coordinate between the
> kernel and xen teams for this; but that should be sorted out among those doing
> the work. I certainly can't see any benefits in terms of source management to
> having them in the same svn repo with the kernel, anyway.
Thanks for your comments!
> And are any of them applicable as patches to today's 2.6.15 linux-2.6 tree?
I haven't tried, for now... Bastian, have you? What are the results?
> > That's I think because xen is still young, and is starting just now its
> > distribution integration, and probably will happen a lot less when it will be
> > integrated with Linux (Linus' tree) and the development of xenolinux will
> > proceed at a different pace than the hypervisor. Then probably it will just be
> > that any xen version will have a minimum linux version needed, just as now a lot
> > of other stuff does, and there will be nothing special in it, except the fact
> > that it needs a kernel compiled for the appropriate subarch).
> In the meantime, to the extent this is an issue it probably means that some
> of this stuff isn't ready for inclusion in etch. I don't see a point in
> uploading two versions of xen to unstable, certainly, if they aren't both
> going to work with the provided kernels.
Of course I agree with you that until the kernel team (together with the
interested people on the xen team) is able to produce working kernels for at
least one version of Xen (and possibly the stable one) it's better for us not to
push for its inclusion.
We are planning to maintain unofficial packages for sarge (for people that want
to use Xen right now) and can do that for etch too, if things don't sort out
before release. It would be nice anyway to have some more support for Xen in
etch (perhaps non segmented glibcs) even if xen itself is not included!