Re: Making QEMU easier for management tools and applications

[Markus Armbruster]

Cc: Eric for netdev_add QAPIfication.

Kevin Wolf <address@hidden> writes:

> Am 28.01.2020 um 11:16 hat Daniel P. Berrangé geschrieben:
>> On Mon, Jan 27, 2020 at 11:38:49PM +0100, Paolo Bonzini wrote:
>> > Il lun 27 gen 2020, 21:11 John Snow <address@hidden> ha scritto:
>> > 
>> > >
>> > > > ./qemu-core <<EOF
>> > > {
>> > >     "machine": "Q35",
>> > >     "memory": "2GiB",
>> > >     "accel": "kvm"
>> > > }
>> > > EOF
>> > >
>> > 
>> > And now you have to keep all the syntactic sugar that is in vl.c. I don't
>> > think a redesign of -readconfig should accept anything less verbose than
>> > 
>> > - machine:
>> >     type: q35
>> >     ram:
>> >        type: memory-backend-hostmem
>> >        size: 2G
>> > - accel:
>> >   - type: kvm
>> > 
>> > And this is not even taking into account disks.
>> > 
>> > I like the idea of refactoring all the syntactic sugar into a pre-pass on
>> > command line options. This is not an entirely new idea, see
>> > https://www.mail-archive.com/address@hidden/msg35024.html.
>> > 
>> > I am afraid that this thread is derailing a bit, with lots of pipe dreams
>> > and no actionable items. How do we get it back in track?
>> 
>> To me the one thing that is clear. No matter what approach we want to
>> take to QEMU configuration/interaction/CLI/etc, one critical bit of
>> work is a pre-requisite...
>> 
>> ...we must finish[1] the QAPI modelling of QEMU's features in some
>> short, finite timeframe. We can't let it drag on for another 5 years
>> or more. I'd say we need a timeframe that is 2 years max, preferrably
>> 1 year.
>> 
>> I don't think we can achieve this by leaving the task up to to the
>> QAPI maintainers alone. It is unreasonable to put such a burden to
>> on a small number of people to both implement & review it all. We
>> need to consider it a project wide priority item so that we can get
>> broader involvement across all maintainers, in closing the gaps.

Thank you, Daniel.  More on it below.

>> I'm not sure if we have any clear list of where our known gaps exist ?
>
> I don't know about a full list, but I've been discussing command line
> QAPIfication a bit with Markus recently because we had the idea of using
> qemu-storage-daemon as a guinea pig for it.

I still like that idea.  We can explore a 100% QAPIfied CLI there with
minimal disruption elsewhere, and without CLI compatibility concerns.
Constraints due to the shared QAPI schema remain, unless we freely
duplicate stuff, which would probably be a bad idea.

> The big one seems to be QOM (and qdev). object-add and device-add are
> both not defined in terms of QAPI. One of them uses an "any" type (which
> results in QObjects with arbitrary content being passed), the other one
> "gen": false (which avoids generating anything from the schema).

These are the known "cheats" in QMP.  There's also netdev_add, but Eric
has patches to QAPIfy it properly.  Eric, I hope you can dust them off.

For CLI, we have numerous options to QAPIfy.  Some of them are trivial.
Others involve QAPIfying substantial code behind them: I don't want a
QAPIfied option to immediately stuff everything into QemuOpts for
outmoded internal interfaces.  Such shortcuts is what got us into the
netdev_add mess.

QAPIfying internal interfaces is one of the areas where we QAPI guys
will need help.

> I know that some more options exist that have unusual syntax and are
> hard to convert to QAPI while maintaining command line compatibility.

Weird semantics can also get in the way.  For instance, when we replaced
-drive with -blockdev, we used the opportunity to ditch block backend
auto-deletion.

> Maybe that should be solved by just designing new options and
> deprecating the old ones.