Xen devel - Apr 2009 - Reconciling multiple Xen flavored development streams

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

> 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