* Avi Kivity <avi@xxxxxxxxxx> wrote: > > You basically have given up control over the quality of KVM by pushing so > > many aspects of it to user-space and letting it rot there. > > That's wrong on so many levels. First, nothing is rotting in userspace, > qemu is evolving faster than kvm is. If I pushed it into the kernel then > development pace would be much slower (since kernel development is harder), > quality would be lower (less infrastructure, any bug is a host crash or > security issue), and I personally would be totally swamped. That was not what i suggested tho. tools/kvm/ would work plenty fine. As i said: > > [...] You are pushing _way_ too much to user-space into different modules > > and maintenance domains, [...] > > > > ( Note that i dont mind user-space tooling per se, as long as it sits together > > with the kernel bits and gets developed, packaged and given to the user > > in the same domain. ) [...] > > Sure the design looks somewhat cleaner on paper, but if the end result is > > not helped by it then over-modularization sure can hurt ... > > Run 'rpm -qa' one of these days. Modern software is modular, that's the > only way to manage it. Of course rpm -qa shows cases where modularization works. But my point was over-modularization, which due to the KVM/qemu split we all suffer from. Modularizing along the wrong interface is worse than not modularizing something that could be. So when designing software you generally want to err on the side of _under_-modularizing. It's always very easy to split stuff up, when there's a really strong technical argument for it. It's very hard to pull the broken pieces back together though once they are in difference domains of maintanence - as then it's usually social integration that has to happen, which is always harder than a technical split-up. 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
