RE: [Xen-devel] Reconciling multiple Xen flavored development streams

[Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>]

> There are a number of very interesting and obviously active projects
> that seem to be developing different forks of the Xen work. There's the
> mainstream "server" Xen in the form of Xen unstable, XenClient and now
> kXen.  All good stuff but as someone working in the space I'm
> interested
> how and if any of this gets merged.  There was a comment about kXen
> targeting the 3.4 release as well as unstable. What does that mean? I'd
> have expected that since 3.4 is frozen the only place it could go is
> unstable.

Not sure who said kxen would make 3.4 -- it's clearly missed the window. I 
think Christian said he'd re-base the code as soon as 3.4 was released. The 
code is certainly a good candidate to get merged to xen-unstable post branch.

The XenClient repo [ http://xenbits.xen.org/xenclient/ ] contains more than 
just the core hypervisor and is a full reference implementation for 
virtualization on x86 client devices, including a modern xen kernel (soon to be 
pvops based), tiny uclibc/busybox/buildroot based filesystem, and the 
'xenvm/xenops' embedded xen toolstack.

The hypervisor tree in the XenClient repo is currently based on a xen-unstable 
snapshot plus some additional client-specific patches that aren't clean enough 
to go into mainline xen yet. The plan is to keep re-basing that to newer xen 
versions, and feeding the patches into xen-unstable as they're ready. 
Ultimately all the client-specific patches should be merged into mainline 
xen-unstable.

Ian 
 
> I apologize if this was discussed at the recent summit and I missed it.
> Just trying to understand if there's a plan for how these separate
> efforts get merged or interact.  There are some pretty significant
> difference in the build systems and large changes in the ioemu code and
> tool (ocaml vs python) amongst other things...
> 
> None of this is a surprise as they're discussed in the roadmap document
> but I've not seen anything that discusses how they interact or merge.
> Insights gratefully accepted.
> 
> Mike
> 
> --
> Mike Dickson <mike.dickson@xxxxxx>
> BladeSystem infrastructure R&D
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel