On 02/26/2010 03:16 PM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx> wrote:
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.
So your answer can be summed up as: 'we wont do what makes sense technically
because others suck even more' ?
I can sum up your this remark as 'whenever you disagree with me, I will
rephrase your words to make you look like an idiot'.
If you believe I'm an idiot, there's no need to have this (or any)
conversation. If not, please refrain from this type of verbal gymnastics.
And it's not just the kernel<->user interface (which btw., for the case of X
is far narrower than what KVM currently has to Qemu).
The issue is a basic question of software design: does kvm-qemu really make as
much sense without the kernel component as with it? The answer is: it will
borderline-work with CPU emulation (and i'm sure there are people making use
of it that way), but 90%+ of the userbase uses it with KVM and vice versa. It
is really a single logical component as far as maintenance goes, and
tools/kvm/ would make quite a bit of sense.
There are two separate questions. Is there room for a kvm-only
userspace component? I believe so, but throwing away the momentum
behind qemu would be foolish.
Does it make sense for such a component to live in linux.git? IMO, no,
and certainly a lot less than libc and X.
--
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
