On Fri, Feb 24, 2006 at 06:32:10PM +0100, Guido Trotter wrote: > On Fri, Feb 24, 2006 at 06:06:22PM +0100, Bastian Blank wrote:
> > It is a sort of kernel. > 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. 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. 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. > > Just to say, how connected xen to linux is: > > For example: There are three kernel trees of xen: > > - from xen-3.0-testing, 2.6.12 > > - from linux-2.6-xen, 2.6.16-rc4 > > - from linux-2.6-merge, 2.6.16-rc3 > > All of them have different needs from xen. And are any of them applicable as patches to today's 2.6.15 linux-2.6 tree? > > The kernels from xen-3.0-testing and linux-2.6-merge works with a 3.0 > > and unstable hypervisor. > > The 3.0 utils only works on the kernel from xen-3.0-testing. The > > unstable utils with the other. But with both hypervisors. > 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. > What do other people in the kernel team think? If the majority of them agree > fine, otherwise are you sure it's not counterproductive to force xen in the > kernel team hands if most of them don't want to touch it, and on the other > hand > to risk driving away other people who just cannot follow the whole linux > business but could work on the xen hypervisor and tools, help coordinate with > xen's upstream, debian glibc and d-i, etc! Especially if you and other people > who would do both can still do it! :) As an erstwhile contributor to the kernel team who's also interested in Xen packaging, you have my answer above... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
