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é <berra...@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
