Re: Making QEMU easier for management tools and applications

[Kevin Wolf <kwolf@redhat.com>]

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

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

I know that some more options exist that have unusual syntax and are
hard to convert to QAPI while maintaining command line compatibility.
Maybe that should be solved by just designing new options and
deprecating the old ones.

Kevin