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

[Avi Kivity]

On 07/21/2011 05:49 PM, Anthony Liguori wrote:
> 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

Connection refused..

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

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

Agree.  A language with built in support for that would be much nicer 
(for migration as well).

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

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

Wow, repositories like mushrooms after the rains.

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

IMO, that's much nicer, if we can keep the C<->HLL bridge clean.  Python 
isn't very good about that (and I wouldn't want it as the main 
implementation language for other reasons).

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

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.  A much smaller job (the 
memory API conversion) is turning out to be no fun at all.

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

It trades off a lot of boilerplate (translated to copy'n'paste with all 
its issues) into 20-line error messages.  Inheriting from a class and 
implementing all of its pure virtuals is a lot easier than doing the C 
equivalent.

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

Yes.

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

--
error compiling committee.c: too many arguments to function