Hi On Thu, Oct 29, 2026 at 5:45 PM Markus Armbruster <[email protected]> wrote: > > Markus Armbruster <[email protected]> writes: > > > Marc-André Lureau <[email protected]> writes: > > > > [Possible improvement to the QAPI/QMP QOM introspection interface...] > > > >>> Thoughts? > >> > >> I like it overall. > >> > >> But this goes beyond the intended scope of the series. > >> Blending/merging QOM type & QAPI type would warrant more design > >> research. So covering child<> & link<> are out of scope of the current > >> qom-qapi series. I think the addition of qapi-type shouldn't be > >> incompatible with a future proposal, after all all properties should > >> have some 'wire' type (link/child are paths). But we can drop it for > >> now or just rename it x-qapi-type until we agree on the new > >> introspection. > >> > >> my2c > > > > Adding @qapi-type with feature unstable means we don't have to worry > > about the external interface now. One less hurdle for merging. I like > > it. > > > > Whether changing the @type values is safe remains somewhat unclear. See > > > > Subject: Property types changed in this series (was: [PATCH v7 00/65] > > Hi) > > Date: Wed, 21 Oct 2026 18:29:40 +0200 > > Message-ID: <[email protected]> > > We're about to miss the soft freeze. Not your fault; I've been awfully > slow reviewing this. > > The series is quite big. If we can't get it merged, we'll have to > rebase and update it. Not good. > > Here's a possible way forward: > > 1. We tweak this series to retain the existing @type values. > > As is, the series changes @type to the QAPI type where applicable. > This is an improvement, and *probably* safe enough, but I'm reluctant > to accept the risk this late in the development cycle. > > I can do the tweaking. It'll be mildly icky, but should go away > fairly soon.
Tbh, I don't think changing @type is going to hurt, and if it effectively does, we still have the rc period or backports as necessary. > > 2. We mark @qapi-type unstable for now. yes > > 3. Try hard to get it merged in time for 11.2. > > We can then improve on top at our leisure: > > * If we convince ourselves that changing @type values is worthwhile and > safe enough, do so early in a development cycle. > > * Hunt down the remaining properties that don't use a QAPI type. > > * Explore more comprehensive improvements to QOM introspection. > > * Settle on a new QOM introspection interface, deprecate the old crap. I think we should flush the queue, because it's natural to stop working on a "topic" when it reaches >50 pending patches. And it prevents other people from joining the effort too. If it takes >6 months to get 50 patches accepted, the QOM-QAPI dilemna is going to stay for a long time :)
