Re: [PATCH v2 4/9] qapi: Implement qapi_dealloc_present_visitor

[Peter Xu <peterx@redhat.com>]

On Fri, Feb 06, 2026 at 09:19:21AM -0300, Fabiano Rosas wrote:
> >> +static void qapi_dealloc_push(Visitor *v, QObject *obj, void *qapi)
> >> +{
> >> +    QapiDeallocVisitor *qdv = container_of(v, QapiDeallocVisitor, visitor);
> >> +    QStackEntry *se = g_new0(QStackEntry, 1);
> >> +
> >> +    assert(obj);
> >> +    se->obj = obj;
> >> +    se->qapi = qapi;
> >> +
> >> +    if (qobject_type(obj) == QTYPE_QLIST) {
> >> +        se->entry = qlist_first(qobject_to(QList, obj));
> >
> > I still don't yet understand why do we care about lists here.
> >
> > I'm trying to guess, what this code wanted to do: we pushed the 1st entry
> > of the list into the stack, trying to make it as a reference for all the
> > items later within the list.
> >
> > But IIUC we can still define the conditiona-dealloc visitor to be even
> > simpler, right?  Say, if the ref qobject has the qlist object, then free
> > the whole list?
> >
> 
> I need to look at this closely, but I think we need to hold the list ref
> so we can walk each of the objects inside of it and free them, then free
> the empty list. When you "free the whole list" that would mean
> qapi_free_<something>, which we can't do here, being already inside
> visitor code; and free(list) doesn't free it's children, of course.

True.

> 
> > IMHO there're three things we need to manage on conditional deallocations:
> > (1) struct, (2) list, (3) alternatives.  All the rest seem to be scalars.
> >
> > So I wonder if we could define this visitor, so that it treats both (2) and
> > (3) the same way (to always dealloc as long as present).
> >
> > That sounds at least making more sense when I picture that in migration
> > parameters: if we have a list in the parameters (e.g. cpr-exec-command), as
> > long as the list is present in the ref, we should free the whole thing
> > completely on the other one being visited.
> >
> 
> Yes, that makes sense. I'm not expecting individual list items to be
> ever updated separately. However, as I said above, I'm not sure whether
> we can free the whole list without some sort of a walk of its
> members. I'll check and get back to you.

My QAPI kongfu is very limited.. but my current understanding is the
visitor framework will make sure everything will be visited properly within
the list, and after each visit to the list entry, it'll finally free the
list structure (in case of dealloc visitor) via qapi_dealloc_next_list().
I believe that's also what the new dealloc_present visitor should rely on.

So my understanding is maybe we don't need to hold any reference to the
list being walked.  However maybe we want to remember we're walking this
list, then no matter how deep we walk into this list, we should stop
checking / referencing the ref object but just always free everything (aka,
fallback to the basic dealloc operations).

When thinking about that, I found maybe it's not that list is special; it's
when the "top level" is special.

Consider if we have a migration parameter that is a nested struct:

  - struct1
    - struct2
      - int
    - struct3
      - boolean

Then if currently we have this value for this parameter:

  - struct1
    - struct2
      - int=1
    - struct3
      - string="foobar"

When we take an update from the user on this specific parameter, and if the
user's input is:

  - struct1
    - struct2
      - int=2
    (omit struct3)

With your current patch, you'll leave struct3 and the sub-field string
untouched.  However, IIUC the current semantics (of migrate_set_parameters,
at least) should be that we use the new data to fully replace the old
struct1 tree, making sure struct3 alone with the string to be unset?

So I wonder if we should just remember the top of the stack (which must be
a qdict), then free anything below that whenever the top element is present
in the ref.

-- 
Peter Xu