* Zachary Amsden <[email protected]> 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.
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)
> 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.
Suckage is there to be fought all the time.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
