Re: [PATCH 0/4] qemu-storage-daemon: QAPIfy --chardev the stupid way

[Kevin Wolf <kwolf@redhat.com>]

Am 28.10.2020 um 08:01 hat Markus Armbruster geschrieben:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > On 26/10/20 11:10, Markus Armbruster wrote:
> >> Kevin's "[PATCH v2 0/6] qemu-storage-daemon: QAPIfy --chardev"
> >> involves surgery to the QAPI generator.  Some (most?) of it should go
> >> away if we deprecate the "data" wrappers due to simple unions in QMP.
> >> 
> >> Do we really need to mess with the code generator to solve the problem
> >> at hand?
> >> 
> >> 
> >> Let's recapitulate the problem:
> >> 
> >> * We want to QAPIfy --chardev, i.e. define its argument as a QAPI
> >>   type.
> >
> > Considering that this is not 5.2 stuff at this point, I would like to
> > suggest again moving chardevs to -object, and ask you to evaluate that
> > option with the agreement that I do the work instead of you. :)

I don't think this is the right thing to do at this point. Making more
use of QOM is an orthogonal problem and would only make solving this one
harder.

The problem we have and we're trying to solve is that we have
chardev-add (which has a QAPI schema) and -chardev (which doesn't). We
want to get an option that is described by the schema, doesn't duplicate
things and is still convenient to use.

Whether this option starts with -chardev or with -object doesn't really
make much of a difference. The QAPI schema you need behind it will be
almost or even exactly the same.

> Replacing -chardev with -object without regressing features would be
> lovely.  One feature in particular: introspection.
> 
> If we manage to fully QAPIfy -object, we should be good.  I understand
> Eduardo is cutting a path through the jungle.

I don't expect many difficulties with the existing -object (famous last
words).

But if you make chardevs user creatable objects first, it becomes much
harder because you just combined two problems (one of which is already
known to be hard) into one large problem.

> I can offer assistance with bridging QAPI schema to QOM.

So, the steps that I would suggest are:

1a. Finish the QAPI schema for object-add

1b. Find some way to unify chardev-add's ChardevBackend and a
    CLI-friendly version of it in the schema

2. Generate QOM boilerplate code from ObjectOptions instead of
   duplicating it in the implementation

3. Convert chardevs to using QOM properites only now

If we do 3. earlier, we'll write code that we want to replace later
anyway. If we even do it in parallel with 1b. we'll additionally get
merge conflicts. And if we do it before 1b. we'll do it without
considering QAPI in detail and will lose any flexibility to change
things in the new interface, which will make 1b. much harder.

Kevin