Eduardo Habkost <ehabkost@xxxxxxxxxx> 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@xxxxxxxxxx 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!
