Cc: Eric for netdev_add QAPIfication.
Kevin Wolf <kw...@redhat.com> 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 <js...@redhat.com> 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/qemu-devel@nongnu.org/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.
