This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "mike.dickson@xxxxxx" <mike.dickson@xxxxxx>
Subject: RE: [Xen-devel] Reconciling multiple Xen flavored development streams
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Date: Thu, 2 Apr 2009 02:30:26 +0100
Accept-language: en-US
Acceptlanguage: en-US
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 01 Apr 2009 18:31:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1238633814.3565.16.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1238596413.3625.25.camel@xxxxxxxxxxxxxxxxxxxxx> <4FA716B1526C7C4DB0375C6DADBC4EA34172EC1B84@xxxxxxxxxxxxxxxxxxxxxxxxx> <1238633814.3565.16.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcmzLe352NxdRS7ASjyFKUO7Xi8tjQAAjPjw
Thread-topic: [Xen-devel] Reconciling multiple Xen flavored development streams
> 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.


Xen-devel mailing list