Re: [Qemu-devel] [RFC] QEMU Object Model

[Anthony Liguori]

On 07/21/2011 08:38 AM, Avi Kivity wrote:
> On 07/21/2011 04:20 PM, Anthony Liguori wrote:

> > static TypeInfo tcp_server_type_info = {
> > .name = TYPE_TCP_SERVER,
> > .parent = TYPE_SOCKET_SERVER,
> > .instance_size = sizeof(TcpServer),
> > .instance_init = tcp_server_init,
> > .class_init = tcp_server_class_init,
> > };
>
> How do the properties become registered? Ah, I see you do have to
> register them. You'd have to do the same in C++, but it would be a lot
> simpler and type-safer (you can use pointers to members, for example,
> and avoid getter/setters where unnecessary).

See git://git.codemonkey.ws/kvm++.git

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.

And it's really not that much nicer than the C version.  The problem 
with C++ is that even though the type system is much, much nicer, it 
still doesn't have introspection or decorators.  These two things would 
be the killer feature for doing the sort of things we need to do and is 
really where most of the ugliness comes from.

> 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.

> > static void register_backends(void)
> > {
> > type_register_static(&tcp_server_type_info);
> > }
> >
> > device_init(register_backends);
> >
> > C++ doesn't reduce this significantly. The big advantage of an
> > approach like this is that its dirt-simple to integrate incrementally.
> > Converting the entire character device layer will only take a few days.
>
> Wouldn't it be dirt simple in C++ as well?

Not incrementally IMHO.

BTW, take at look at http://repo.or.cz/w/qemu/aliguori.git/blob/qdev2:/qsh

Part of my thinking here is that the few monitor commands we need to 
work with plugs end up being 90% of what we do today.  For instance, all 
of the chardev commands get mapped to generic commands:

chardev_add/-chardev   ->    plug_add
chardev_del            ->    plug_del
query-chardev          ->    plug_list base=chardev

The same is true for blockdev, netdev, and eventually all of the device 
model.

All of the complexity around reading command lines and config files 
should be done in a python front end.   qsh is an ad-hoc attempt at 
doing exactly that.  There is already an import command that handles a 
git-style command line file.

> We can change the language first.

My view is roughly this:

1) introduce type system and update build system

2) convert each backend, add compatibility handlers to preserve existing 
monitor commands and command line arguments.  deprecate everything to be 
removed in qemu 2.0.

3) introduce a new front end written in Python that only works with the 
plug interfaces

4) convert the device model.  compatibility will be hard to maintain but 
I think it's doable.

5) declare qemu 2.0, remove all of the compatibility stuff, and 
potentially move it to a new python script for legacy usage.

At this point, qemu would no longer be an executable that was directly 
invoked by a user.  They would use a wrapper script to provide the 
functionality of today's qemu.  Management software could launch the 
daemon on their own.

C++ doesn't eliminate any of these steps.  IMHO, it doesn't tremendously 
simplify any of these steps either.

I think *good* C++ could provide some value by eliminating the 
possibility of buffer overflows, use-after-free, memory-leaks, etc.  But 
that's icing on the cake.

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.

Regards,

Anthony Liguori