Re: [PATCH RFC 00/10] QOM: Introduce OBJECT_COMPAT class

[Peter Xu <peterx@redhat.com>]

On Fri, Dec 12, 2025 at 12:28:21AM +0900, Akihiko Odaki wrote:
> I'm actually less sure if the first half makes sense than the second half.
> 
> Exporting Property from QDEV did make me think it may be polluting the
> codebase with QDEV-specifics, but its motivation (creating properties
> without defining accessors) is clear and it meets its requirement.
> 
> The motivation is less concrete for the first half. It says the current code
> is explicit, but it is a relative term. I'm not sure if specifying
> TYPE_OBJECT_COMPAT is less explicit (or more implicit) than calling
> object_apply_compat_props(). Also, having a class for compat props but not
> for global props makes the decision look arbitrary. It is nice to have some
> clarification on these.

Thanks for the comments, Akihiko.  I can explain.

I explicitly only included object_apply_compat_props() in the current
OBJECT_COMPAT class (rather than set_globals()) is almost two-fold:

  - Inclusion of qdev_prop_set_globals() makes the 1st half start to depend
    on the 2nd half, that I don't see it strictly necessary.  E.g., one
    immediate motivation of me looking at this problem is Vladimir's series
    on virtio-net/tap [1].

    That series should only need patch 1-6 of this series as minimum to
    enable machine compat properties for TAP (after QOMify, if that makes
    sense on its own).

  - qdev_prop_set_globals() itself has a trivial dependency currently
    against qdev hotpluggable or not:

    object_apply_global_props(OBJECT(dev), global_props(),
                              dev->hotplugged ? NULL : &error_fatal);

    There's way to decouple that I guess, however I just don't see it
    necessary yet.  The only real user will be migration object, which
    doesn't need to depend on this anyway, as long as Property APIs can be
    exported.

Do you think we should keep open-code object_apply_compat_props() instead?

In reality, that also works for me at least on figuring out the current
problem [1], and if Property API exported I can also open code it for
migration object.  It's just that IMHO it's cleaner we have the light class
to do this (so as to avoid providng post_init() hooks all over the places).

[1] https://lore.kernel.org/all/20251030203116.870742-1-vsementsov@yandex-team.ru/

-- 
Peter Xu