Re: [RFC 3/5] convert code to object_new_dynamic() where appropriate

[Peter Xu <peterx@redhat.com>]

On Thu, Oct 31, 2024 at 03:53:48PM +0000, Daniel P. Berrangé wrote:
> In cases where object_new() is not being passed a static, const
> string, the caller cannot be sure what type they are instantiating.
> There is a risk that instantiation could fail, if it is an abstract
> type.
> 
> Convert such cases over to use object_new_dynamic() such that they
> are forced to expect failure. In some cases failure can be easily
> propagated, but in others using &error_abort maintainers existing
> behaviour.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  chardev/char.c                   |  5 ++++-
>  hw/core/bus.c                    |  2 +-
>  hw/core/cpu-common.c             |  2 +-
>  hw/core/qdev.c                   |  4 ++--
>  hw/i386/x86-common.c             |  5 ++++-
>  hw/i386/xen/xen-pvh.c            |  2 +-
>  hw/vfio/common.c                 |  6 +++++-
>  hw/vfio/container.c              |  6 +++++-
>  qom/object_interfaces.c          |  7 ++-----
>  qom/qom-qmp-cmds.c               | 15 +++++++++------
>  tests/unit/check-qom-interface.c |  3 ++-
>  tests/unit/test-smp-parse.c      | 20 ++++++++++----------
>  12 files changed, 46 insertions(+), 31 deletions(-)

I think we could leave the test cases alone without _dynamic(), because
they do test static types (even if they used "opaque"..), and they should
really (and forever) assert on failures..

IMHO we should keep _dynamic() usages small if we'd like to introduce it,
only in the paths where its failure will be properly handled.  Basically, I
think we shouldn't use _dynamic() if we know it'll be error_abort.. because
that's fundamentally identical to object_new().

A small set of _dynamic() usages also keep us easy to track all the paths
where QEMU can create some totally random objects too.

-- 
Peter Xu