Comments on: Kernel developers don’t get Xen

By: pkt

pkt — Tue, 23 Jun 2009 11:45:10 +0000

They merge whatever they can merge. It is easy to look at things from your POV only but try to be an x86 arch maintainer for a while and see what you ‘ll think then :)

The code that was not merged was all sorts of “if (xen)” stuff that makes the code even more complex and hard to debug. The popularity of the project does play a role and whenever Linus and x86 maintainers can merge something they typically do.

But the linux kernel powers *way* more stuff than Amazon and other cloud stuff and destabilizing it to please xen users would
probably be a wrong decision.

If merging the hypervisor to Linux proper is not possible, then
some other way needs to be found that allows the x86 tree to keep changing as fast as it does now without having complaints from users “oh, you broke xen again”.

By: kev009

kev009 — Thu, 18 Jun 2009 03:48:17 +0000

@regala
You took my post completely out of context and blatantly ignored the concluding paragraph.

I called for the merging of the conservative patches that said developers have approved of on the ML various times. And it appears that they are taking this course of action finally (2.6.31 merge so far has some xen supporting code for dom0).

Nowhere did I say or imply “merge dom0 functionality all at once, right now!!”. This would indeed be stupid. Getting full dom0 support will take several kernel cycles. It has to start somewhere, however small.

By: regala

regala — Wed, 17 Jun 2009 11:24:51 +0000

@kev009: I can understand your frustration. I for one would really like to have dom0 in kernel upstream. But as long as there are patches for it, I wouldn’t think as boldly as you are. You are exactly sounding like what Linus refers to in this very mail. Did you run the command he gave ? I did. I know what it means.
Kernel development is hard enough to deal with unbacked with proof statements: it will be difficult to merge without touching, destabilizing virtually all other subsystems. You are blindly accusing developers who have tried and managed to keep hundreds of thousands of lines of code clean, and merging Xen dom0 code would just sound and be totally incoherent in this respect. Better not merging dirty code than having to clean it up afterwards. The strategy Jeremy saud he would like to be taken for that matter is unrealistic in regards of many other out-of-tree kernel projects. I clearly understands how it can be quite hard to deal with but don’t blame the fact that xen dom0 support for Linux was coded with speed of development in mind. EVERY out-of-tree projects have to pass the review step and if concerns are raised, they HAVE to be addressed, no matter what is the popularity of the project.
Xen has much to gain too, by going thru this process, the larger the code is, the longer the review-and-fix process is.

By: kev009

kev009 — Sat, 06 Jun 2009 20:19:25 +0000

@Scorp
I have used both. They have their place in my toolbox as well, specifically for virtual hosting where many copies of the same OS are being used.

Xen and KVM are used a bit differently. They let you run complete Linux operating systems with the vendor kernel, very useful for different versions and also when doing software QA. Of course, they will also run non-Linux kernels which is where they really shine.

What I really would like to see is more documentation on LXC, Linux native containers. This is openvz/linux-vserver support built into the vanilla kernel. It has been in the kernel for a while but nobody is talking about it! I suppose once libvirt supports it well, it should be more accessible to the masses.
http://lxc.sourceforge.net/

By: Scorp

Scorp — Sat, 06 Jun 2009 17:06:50 +0000

Have you ever tried solutions like openvz or linux-vserver?
IMHO are good solutions, even better xen for linux virtualization if you need best performances from your machines.

By: kev009

kev009 — Sat, 06 Jun 2009 08:44:06 +0000

@Egan
There seems to be a lot of sentiment toward Xen in the Linux kernel and most (including Linus) point to blanket statements like that (“Xen is hard to merge”) rather than specific code critique/improvements. That’s why it all shouldn’t go in in one merge. Jeremy has separated a lot of the work and has some basic dom0 patches. By accepting these now, it will at least lighten the load Jeremy and distros have to carry to get Xen dom0 kernels built. Then, the focus can shift to cleaning up Xen and merging in more/better/cleaner dom0 code.

My statement is this:
Xen is in wide use. It is hurting more people by having it not in the kernel than having some “hard to merge” code in the kernel. Let us have rudimentary Xen dom0 support in the kernel now, then gradually fix and improve both it (dom0 code) AND xen itself over time.

By: egan

egan — Sat, 06 Jun 2009 08:30:41 +0000

Can you please read that => http://lkml.org/lkml/2009/6/2/352
What is your answer ?