Mailing List Archive

> 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@hp.com>
> BladeSystem infrastructure R&D
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

On Wed, Apr 1, 2009 at 7:33 AM, Mike Dickson <mike.dickson@hp.com> wrote:
> 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.

I meant that KXen will be developed on top of 3.4 (to have a stable
base) and that we'll merge it into xen-unstable.

christian

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

On Wed, 2009-04-01 at 22:02 +0000, Ian Pratt wrote:
> 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.

That makes more sense. Certainly its difficult to stabilize something
against unstable so having the 3.4 release as a base makes sense.

>
> 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.

This is where I've spent my time recently. I've built the tree and
booted it on a couple of systems. I like the more modular approach when
building the components actually. That's necessary of course given the
use of uClibc and buildroot. I'm curious how the build system and the
modularity gets fitted against the current server tree. Also how does
the ocaml work get reconciled against the current python tools approach
in the main xen tree. The current ocaml stuff is more minimalist which
makes it a nice fit for the client hypervisor or an embedded approach.
Do the tool stacks live side by side and when a build is done I
configure which stack to use? Or do you anticipate this work will be
kept separate.

> 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.

That's what I suspected. So is the likely outcome then that the work
converges around a single version of Xen (as patches mature the
XenClient and kXen work gets merged into unstable and therefore into a
future release)? I can see a similar convergence around the qemu-dm
code. Toolstacks stay separate and perhaps I select which stack I need
when building this unified Xen?

It's great to see all the healthy development activity addressing
different use cases. I was just curious if the plan was to keep these
as separate forks or merge them into "core Xen" as was practical. Thanks
for clarifying.

Mike




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

> This is where I've spent my time recently. I've built the tree and
> booted it on a couple of systems. I like the more modular approach
> when building the components actually. That's necessary of course given the
> use of uClibc and buildroot. I'm curious how the build system and the
> modularity gets fitted against the current server tree. Also how does
> the ocaml work get reconciled against the current python tools approach
> in the main xen tree. The current ocaml stuff is more minimalist which
> makes it a nice fit for the client hypervisor or an embedded approach.
> Do the tool stacks live side by side and when a build is done I
> configure which stack to use? Or do you anticipate this work will be
> kept separate.

I like the configurable approach and it seems a good direction to head in.

Having a complete 'reference implementation' of the client hypervisor complete with tiny dom0 filesystem is making development much easier than worrying about all the different distros that the hypervisor and toolstack might be installed on, and we're ending up with something that's purpose-built, smaller, and optimized. There's a strong argument for doing something similar for server.

Ian




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