[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: KVM call for agenda for 2020-10-06
From: |
Markus Armbruster |
Subject: |
Re: KVM call for agenda for 2020-10-06 |
Date: |
Sat, 10 Oct 2020 06:41:48 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
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:
>
> 20201009160122.1662082-1-ehabkost@redhat.com">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!