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-ehabk...@redhat.com > > 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. -- Eduardo
