On Fri, Nov 13, 2020 at 10:46:02 +0100, Kevin Wolf wrote: > Am 12.11.2020 um 19:34 hat Eric Blake geschrieben: > > On 11/12/20 11:28 AM, Kevin Wolf wrote: > > > Introduce alias definitions for object types (structs and unions). This > > > allows using the same QAPI type and visitor for many syntax variations > > > that exist in the external representation, like between QMP and the > > > command line. It also provides a new tool for evolving the schema while > > > maintaining backwards compatibility during a deprecation period. > > > > Cool! Obvious followup patch series: deprecate all QAPI members spelled > > with _ by making them aliases of new members spelled with -, so that we > > can finally have consistent spellings. > > Ah, that's a nice one, too. I didn't even think of it. Another one I'd > like to see is deprecation of SocketAddressLegacy. > > There is one part missing in this series that we would first need to > address before we can actually use it to evolve parts of the schema that > are visible in QMP: Exposing aliases in introspection and expressing > that the original name of something is deprecated, but the alias will > stay around (and probably also deprecating an alias without the original > name or other aliases). > > If we can easily figure out a way to express this that everyone agrees > with, I'm happy to include it in this series. Otherwise, since the first > user is the command line and not QMP, I'd leave that for the future. > > For example, imagine we have an option 'foo' with a new alias 'bar'. If > we just directly expose the alias rule (which would be the simplest > solution from the QEMU perspective), management will check if the alias > exists before accessing 'bar'. But in the final state, we remove 'foo' > and 'bar' is not an alias any more, so the introspection for 'bar' would > change. Is this desirable? > > On the other hand, we can't specify both as normal options because you > must set (at most) one of them, but not both. Also exposing things as > normal options becomes hard with wildcard aliases (mapping all fields > from a nested struct), especially if unions are involved where some > options exist in one or two variants, but not in others. > > Given this, I think just exposing the alias rules and letting the > management tool check both alternatives - if the alias rule or the > future option exists - might actually still be the least bad option. > > Hmm, I guess I should CC libvirt for this discussion, actually. :-) I can see how that simplifies things for qemu in the long run, but to be honest, if you then deprecate the old name, libvirt will need to add a translation table for it. Either explicit by detecting the new name and adapting the code or by adding a lookup table or something. This would be needed as if you then remove the alias itself we'd no longer be able to use it, so I'm not entirely a fan of it, especially the deprecation bit.