* 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. 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
