On 03/18/2010 01:48 PM, Ingo Molnar wrote:
It's not inevitable, if the projects are badly run, you'll have high
latencies, but projects don't have to be badly run.
So the 64K dollar question is, why does Qemu still suck?
Where people sent patches, it doesn't suck (or sucks less). Where they
don't, it still sucks. And it cost way more than $64K.
If moving things to tools/ helps, let's move Fedora to tools/.
How is a patch for the qemu GUI eject button and the kvm shadow mmu related?
Should a single maintainer deal with both?
We have co-maintainers for perf that have a different focus. It works pretty
well.
And it works well when I have patches that change x86 core and kvm. But
that's no longer a single repository and we have to coordinate.
Look at git log tools/perf/ and how user-space and kernel-space components
interact in practice. You'll patches that only impact one side, but you'll see
very big overlap both in contributor identity and in patches as well.
Also, let me put similar questions in a bit different way:
- ' how is an in-kernel PIT emulation connected to Qemu's PIT emulation? '
Both implement the same spec. One is be a code derivative of the other
(via Xen).
- ' how is the in-kernel dynticks implementation related to Qemu's
implementation of hardware timers? '
The quality of host kernel timers directly determines the quality of
qemu's timer emulation.
- ' how is an in-kernel event for a CD-ROM eject connected to an in-Qemu
eject event? '
Both implement the same spec. The kernel of course needs to handle all
implementation variants, while qemu only needs to implement it once.
- ' how is a new hardware virtualization feature related to being able to
configure and use it via Qemu? '
Most features (example: npt) are transparent to userspace, some are
not. When they are not, we introduce an ioctl() to kvm for controlling
the feature, and a command-line switch to qemu for calling it.
- ' how is the in-kernel x86 decoder/emulator related to the Qemu x86
emulator? '
Both implement the same spec. Note qemu is not an emulator but a binary
translator.
- ' how is the performance of the qemu GUI related to the way VGA buffers are
mapped and accelerated by KVM? '
kvm needs to support direct mapping when possible and efficient data
transfer when not. The latter will obviously be much slower. When
direct mapping is possible, kvm needs to track pages touched by the
guest to avoid full screen redraws. The rest (interfacing to X or vnc,
implementing emulated hardware acceleration, full-screen mode, etc.) are
unrelated.
They are obviously deeply related.
Not at all. kvm in fact knows nothing about vga, to take your last
example. To suggest that qemu needs to be close to the kernel to
benefit from the kernel's timer implementation means we don't care about
providing quality timing except to ourselves, which luckily isn't the case.
Some time ago the various desktops needed directory change notification,
and people implemented inotify (or whatever it's called today). No one
suggested tools/gnome/ and tools/kde/.
The quality of a development process is not
defined by the easy cases where no project unification is needed. The quality
of a development process is defined by the _difficult_ cases.
That's true, but we don't have issues at the qemu/kvm boundary. Note we
do have issues at the qemu/aio interfaces and qemu/net interfaces (out
of which vhost-net was born) but these wouldn't be solved by tools/qemu/.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
