On 03/18/2010 12:10 PM, Ingo Molnar wrote:
It's not a 1:1 connection. There are more users of the KVM interface. To
name a few I'm aware of:
- Mac-on-Linux (PPC)
- Dolphin (PPC)
- Xenner (x86)
- Kuli (s390)
There must be a misunderstanding here: tools/perf/ still has a clear userspace
interface and ABI. There's external projects making use of it: sysprof and
libpfm (and probably more i dont know about it). Those projects are also
contributing back.
So it seems it is possible to scale the package wall.
Still it's _very_ useful to have a single reference implementation under
tools/perf/ where we concentrate the best of the code. That is where we make
sure that each new kernel feature is appropriately implemented in user-space
as well, that the combination works well together and is releasable to users.
That is what keeps us all honest: the latency of features is much lower, and
there's no ping-pong of blame going on between the two components in case of
bugs or in case of misfeatures.
That would make sense for a truly minimal userspace for kvm: we once had
a tool called kvmctl which was used to run tests (since folded into
qemu). It didn't contain a GUI and was unable to run a general purpose
guest. It was a few hundred lines of code, and indeed patches to kvmctl
had a much closer correspondence to patches with kvm (though still low,
as most kvm patches don't modify the ABI).
Same goes for KVM+Qemu: it would be so much nicer to have a single,
well-focused reference implementation under tools/kvm/ and have improvements
flow into that code base.
That way KVM developers cannot just shrug "well, GUI suckage is a user-space
problem" - like the answers i got in the KVM usability thread ...
The buck will stop here.
Suppose we copy qemu tomorrow into tools/. All the problems will be
copied with it. Someone still has to write patches to fix them. Who
will it be?
The kernel/userspace interface really isn't the difficult part. Getting
device emulation working properly, easily and fast is.
The kernel/userspace ABI is not difficult at all. Getting device emulation
working properly, easily and fast indeed is. And my experience is that it is
not working properly nor quickly at the moment, at all. (see the 'KVM
usability' thread)
Getting device emulation working properly often involves putting certain
pieces that are currently done in Qemu into kernel-space. That kind of
'movement of emulation technology' from user-space component into the
kernel-space component [or back] would very clearly be helped if those two
components were in the same repository.
Moving emulation into the kernel is indeed a problem. Not because it's
difficult, but because it indicates that the interfaces exposed to
userspace are insufficient to obtain good performance. We had that with
vhost-net and I'm afraid we'll have that with vhost-blk.
And i have first-hand experience there: we had (and have) similar scenarios
with tools/perf routinely. We did some aspects in user-space, then decided to
do it in kernel-space. Sometimes we moved kernel bits to user-space. It was
very easy and there were no package and version complications as it's a single
project. Sometimes we even moved bits back and forth until we found the right
balance.
That's reasonable in the first iterations of a project.
--
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
