Anthony Liguori wrote:
Avi Kivity wrote:
No argument. But some kernel features will require major rework in
qemu before we can support them properly. We'll still want to bring
them to users quickly so users can enjoy them (and we can enjoy users
testing them). Waiting for a qemu rework may take a while, and we'll
lose valuable feedback.
Then we're failing. If a particular implementation of a feature is
acceptable for kvm-userspace users, and we don't take it in QEMU
without requiring a huge amount of different work, then it suggests
something is broken about the QEMU process.
Example: SMP.
Example: vlan API.
For this kind of work, we can provide kvm-userspace.git as a kind of
playground where these experiments may be made. kvm-userspace.git
exists to support kvm.git; while qemu.git has a life of its own and
more stringent barriers to acceptance.
As long as people are using kvm-userspace.git instead of qemu.git,
we're failing IMHO. If kvm-userspace.git is basically the equivalent
of the x86 git kernel tree, linux-next, or something like that, then
that's a good thing.
That's definitely a long term goal, but qemu is not yet at a point where
it is easy to implement new features efficiently. Once it reaches that
state, kvm-userspace will become a simple staging ground (or even
disappear entirely).
--
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
