[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Modular Xen

  • To: "David Pilger" <pilger.david@xxxxxxxxx>
  • From: "Henning Sprang" <henning_sprang@xxxxxx>
  • Date: Fri, 19 Jan 2007 21:23:39 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>
  • Delivery-date: Fri, 19 Jan 2007 12:23:12 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=iNc3YCmD/T+bauwKgEbicd0Gu+G0xrm52DCLJsd7oQr9k1Q0yYQaREv3EmTtpsngPsEPgavOcVHHttY3V0kboG+X0/X0bQgzguH/l+FjdsewXQn8cTvo5hQsqDA7vRZYDNoPcuEjNV/84FIXda43k+v1rzXolnRbSTeY8Dfb3qw=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

As can be seen in some of my rants, I am also in some love/hate
relationship with Xen.

I agree about general doubts on the maturity and robustness of Xen,
the openness  of it's development model and lacking
(Still waiting to hear why there's no NEWS file for user visible
changes in new versions, as most high quality Open Source projects are
expected to have, and actually have - there might be some reluctance
to tell me that XenEnterprise licenses sell too bad if using the GPL
stuff is too easy - just a thought :) )

But I don't understand this one:

On 1/15/07, David Pilger <pilger.david@xxxxxxxxx> wrote:
On 1/15/07, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
> I personally don't think this is worthwhile, at least right now. The Xen
> image is about 1MB in memory (including text, data and bss) which is very
> little even for portable devices these days.

Hi Keir, I look at it from the perspective of extending instead of embeding...

In what do you want to embed Xen in? In an embedded system?

This way, Xen will be easily ported to any environment,

What do you mean? other architectures, like ARM and MIPS or something?
A PPC port is on it's way.

The Xen core is not so big as you suggest, I am no low-level
programmer to be able to judge but at least in compile time, the Linux
kernel takes most of the time when building Xen.

And the ACM /sHype stuff you talk about _is_ in fact optional and not
built by default. (I agree with doubts of it's usefullness in the
current state and without further explanation of a usage scenario, see
my post about this)

it will be
much more easier to program extensions, etc...

Look at the Xen python apis and programs and start programming extensions.
If you mean not the tools, but the Xen core, what type of extensions
do you mean?
There seems to be a flexible architecture, for example to implement
different CPU schedulers.

What exactly are you missing?

If you want a small and sleek virtualization api to port on whatever
other architecture, you might want to look at kvm and lhype/ll. But
for hardware virtualization - how many platforms apart from AMD SVM,
Intel VT/x and IBM Power support this? So, there's nothing to port
them to, I guess.

Kvm is part of mainstream linux and will even get PV sometime soon.
With a GRML live cd, you can apt-get install kvm, load the module, and
start a windows  in about 5 minutes. In case you tried both - remember
how long ot took you to get your first Xen VM? That's astonishing for
such a new technology!
If you are for simplicity and something very small, that might be of interest.

That doesn't mean Xen hasn't interesting and good upsides compared to kvm.

I am, as said in another thread, also sceptical about some of Xen's
features, and some important things might be missing ( I heard no
transaction management for migration exists?!)
But that's what wishlist bugs in the BTS are for... not random,
un-detailed rants about being "not modular enough".

My opinion on this opinion :)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.