On 02/26/2010 02:46 PM, Ingo Molnar wrote:
* 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.
I'll wait until we have tools/libc and tools/X. After all, they affect
a lot more people and are concerned with a lot more kernel/user
interfaces than kvm.
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.
You're the only one who suffers from it. Everyone else is happy with
adding features in the modules that implements them, be it kvm, qemu,
libvirt, or virt-manager (to name one tool stack out of several).
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.
As it happens, the kvm and qemu development community has a large
overlap. Many developers read both lists, contribute to both projects,
and participate on the same weekly call. While we had difficulties
pushing patches to qemu in the past, that's behind us, and qemu is now
accepting patches at a much higher rate than kvm.
Technically, it is obvious that the userspace and kernel components are
separate projects. All that remains is the social divide. Since
everyone (except you) is mostly happy, I see no reason to change.
--
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
