On 07/21/2011 06:45 PM, Anthony Liguori wrote:
See git://git.codemonkey.ws/kvm++.git
Connection refused..
Sorry, stupid EC2. Try http://git.codemonkey.ws/git/kvm++.git
You don't have permission to access /git/kvm++.git/ on this server.
It's exactly the same object model, but in C++. Some things are nicer,
some things are not nicer. It's not quite a slam dunk.
But what really concerned me about it was that I quickly realized that
it was going to be mostly write-only code. The C++ tricks that you
need to do to make it all work well are extremely obscure. It requires
template meta-programming, every obscure detail about partial
specialization, etc.
Yes, that's a big worry. Is all of that exposed to the implementer? Or
just in the framework?
I was able to get it mostly hidden but not entirely. The biggest
problem is that even with a semi normal looking function, a simple
mistake like passing in the wrong number of arguments can result in an
undecipherable error message. It's not bad to debug if you're used to
it but very difficult to just slip in to a C project.
I have to agree with this. You can write neat domain specific languages
in C++ but the nice abstractions break the minute you misplace a comma.
There is quite a lot of boilerplate - around half the code of
tcp.[ch].
It may be simple to create a new type to the author of the framework,
but I doubt it would be simple to others. There would be a lot of
cut'n'paste.
Yup. That's the price you pay for using C over C++. But the ratio is
only true for simple types. Complex types (look at chrdrv.h), the
ratio is much lower.
chrdrv.c is almost 100% boilerplate.
Sure, but so is qemu-char.c and block.c. It's not really different
from what we have today.
I'm trying to get us away from boilerplate, actually writing the code
that matters?
Maybe it's an unsolvable problem. With a low level language, you get to
write boilerplate. With a high level language, the compiler writes it
for you, and a whole lot more you don't want.
But it's a big problem. Those conversions suck the life force out of
whoever's doing them, and then he comes back as zombie to haunt us at
the next kvm forum. It's not just type safety at stake here.
The big problem with this plan is that steps 2 and 4 are very difficult
and yet we see no gains while it's being done.
So at least with the chardev conversion, we'll get the ability to
dynamically add character devices and change the settings of a chardev
after start up. Both of these are important features.
I think done properly, it all can have incremental value. I worry
about converting the device model.
A much smaller job (the
memory API conversion) is turning out to be no fun at all.
Yeah, I don't know how to fix that. This is why I'm starting with the
backends. They're much smaller than the device model.
Ok. Let's hope you've hit on the least-bad tradeoff. I'm sceptical,
but I don't have anything concrete to offer.
I don't ever see the device model being written in something other
than C/C++ too. Having a GC in the VCPU thread would be a major issue
IMHO.
We get the equivalent of GC every time a vcpu thread is scheduled out so
an iothread or an unrelated process can run.
But you can control this with pinning, priorities, etc. You cannot
with GC.
And in quite a lot of systems, GC pauses are very, very long.
I expect the number of objects we'll have will be very small (O(info qdm
| wc -l)). They'll also be very long lived. Won't that make the GC
rather fast?
It will hurt hard realtime
guests, but these are only interesting to a small subset of users.
I think that if we can get the data path to run in pure C, and have the
GC HLL involved only when the device model is reconfigured, then we have
an acceptable tradeoff. I don't claim that I know how to do this,
though. This is a really hard problem, mostly due to the huge size of
qemu.
This is one very good thing about having a common object model that's
pluggable (which is what QOM is all about). It becomes relatively
easy to build with CONFIG_PCI=n, then build a shared library that
implements a new PCI layer in your favorite HLL so that you can
experiment.
If I wanted a new PCI layer I'd write one outside of qemu. Getting PC
emulation is probably easier than converting all of qemu - see tools/kvm
(though they're not doing full emulation, just the subset needed to get
Linux going). I want the old layer, it has a lot of knowledge sweated
into it and it's very compatible with itself and with the guests it has
booted.
--
error compiling committee.c: too many arguments to function
