On 02/27/2010 07:25 PM, Ingo Molnar wrote:
* Zachary Amsden<zamsden@xxxxxxxxxx> wrote:
[...]
Second, it's not over-modularized. The modules are the individual
components of the architecture. How would you propose to put it
differently. They really can't naturally combine. And with the
code quality of qemu in general being problematic by Linux kernel
standards, it's not natural to move the device emulation directly
into the kernel module. So this is why we are where we are today.
I'm not talking about moving it into a kernel _module_ - albeit that
alone is a worthwile thing to do for any performance sensitive hw
component.
Moving qemu into the kernel is preposterous. It's a huge code base
(even a stripped down version) with many external dependencies. You're
converting a guest crash into a host crash, and a simple binary update
into a reboot.
What makes sense is identifying the performance critical bits and
creating generally useful kernel interfaces that can be used to speed
them up, or kvm-specific kernel accelerations. Example include
preadv/pwritev (generic) and vhost-net (specific).
I was talking about the option of a clean, stripped down Qemu base
hosted in the kernel proper, in linux/tools/kvm/ or so. If i were
running a virtualization effort it would be the first place i'd
consider to put my tooling into.
It would be a no-brainer: most of the devs come from the KVM side, and
KVM itself makes little sense without Qemu, and Qemu makes little sense
without KVM these days. (and i know about the non-KVM and non-x86
roots of Qemu - still, it's not a significant piece of usage today)
It's true that qemu development is dominated these days by kvm
development. If the qemu community was dysfunctional (as it once was)
then it makes sense to fork it. But it isn't, so it doesn't.
Note also that kvm is not x86 only.
Third, it's the maintainers upstream who are in charge of KVM
quality as a whole - when you are talking about upstream code
quality, and the package maintainers who are in charge of KVM
quality as a whole - when you are talking about a distro. This is
nothing new - it's just a statement of decentralization.
It's certainly nothing new. Nor was the suckage of CVS newup until
Git came along and changed the game on a fundamental basis.
Bitkeeper deserves some credit here.
Suckage is there to be fought all the time.
Send patches, not flames.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
