Re: KVM call for agenda for 2020-10-06

[Kevin Wolf <kwolf@redhat.com>]

Am 07.10.2020 um 19:50 hat Paolo Bonzini geschrieben:
> On 06/10/20 20:21, Stefan Hajnoczi wrote:
> >     * Does command-line order matter?
> >         * Two options: allow any order OR left-to-right ordering
> >         * Andrea Bolognani: Most users expect left-to-right ordering,
> > why allow any order?
> >         * Eduardo Habkost: Can we enforce left-to-right ordering or do
> > we need to follow the deprecation process?
> >         * Daniel Berrange: Solve compability by introducing new
> > binaries without the burden of backwards compability
> 
> I think "new binaries" shouldn't even have a command line; all
> configuration should happen through QMP commands.  Those are naturally
> time-ordered, which is equivalent to left-to-right, and therefore the
> question is sidestepped.  Perhaps even having a command line in
> qemu-storage-daemon was a mistake.
> 
> For "old binaries" we are not adding too many options, so apart from the
> nasty distinction between early and late objects we're at least not
> making it worse.
> 
> The big question to me is whether the configuration should be
> QAPI-based, that is based on QAPI structs, or QMP-based.  If the latter,
> "object-add" (and to a lesser extent "device-add") are fine mechanisms
> for configuration.  There is still need for better QOM introspection,
> but it would be much simpler than doing QOM object creation via QAPI
> struct, if at all possible.

I would strongly vote for QAPI-based. It doesn't have to be fully based
on QAPI structs internally, but the defining property for me is that the
external interface is described in the QAPI schema (which implies using
QAPI structs for the external facing code).

Not only is it a PITA to work with things like "gen": false or "props":
"any", but having two systems to configure things side by side is also
highly inconsistent.

I have recently discussed object-add with Markus, or to be more precise,
a QAPIfied --object in qsd wrapping it. This doesn't work well without
having a schema. I believe the right thing to do there is build a QAPI
schema describing the existing QOM properties in a first step (which
already gives you all of the advantages of QAPI like introspection), and
then in a second step generate the respective QOM code for initialising
the properties from the schema instead of duplicating it.

This can get challenging with dynamic properties, but as far as I can
see, user creatable objects only have class properties or object
properties created right in .instance_init (which should be equivalent).

As the number of user creatable objects isn't too large, this shouldn't
be too hard. I'm less sure about device-add, though in theory the same
approch would probably result in the best interface.

Kevin