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/.
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.
Both implement the same spec. One is be a code derivative of the other
(via Xen).
The quality of host kernel timers directly determines the quality of
qemu's timer emulation.
Both implement the same spec. The kernel of course needs to handle all
implementation variants, while qemu only needs to implement it once.
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.
Both implement the same spec. Note qemu is not an emulator but a binary
translator.
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.
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/.
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
--
