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

[Markus Armbruster <armbru@redhat.com>]

Eduardo Habkost <ehabkost@redhat.com> writes:

> On Thu, Oct 08, 2020 at 10:03:45AM +0200, Kevin Wolf wrote:
>> 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).
>
> I've just submitted a series to ensure 100% of
> TYPE_USER_CREATABLE types have only class properties:
>
> https://lore.kernel.org/qemu-devel/20201009160122.1662082-1-ehabkost@redhat.com

Lovely idea!

Additional benefit: QOM introspection becomes more useful.

>> 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.
>
> Doing the same for all user creatable device types would be nice
> too.  We can use the property locking mechanism from the series above
> to find out how bad the situation is.

Yes, please!