While looking at possible Rust APIs for object_new/qdev_new (one of the functions that rust/hw/char/pl011 uses via FFI) I noticed that the support for modules in QOM APIs is quite random.
In particular, loading modules is done by object_initialize() and qdev_new(), but not by object_new(); furthermore, the loading code is duplicated between object_initialize() and module_object_class_by_name(). This series fixes that. Patches 1-2 are small cleanups. Patches 3-4 let object_new() use a module if the type is not present, like object_initialize() already does. To get there, all calls to type_get_by_name() are changed to either type_get_by_name_noload() (the old function) or type_get_or_load_by_name() (which looks at modules like object_initialize() and module_object_class_by_name() do). This is enough to let Rust code use a single function object_new() to create QOM objects; the function can be wrapped to allow writing something like "PL011State::new()" instead of object_new(TYPE_PL011) as *mut PL011State". Patch 5 finally allows modularized user-creatable classes, which are not allowed just because the code uses the non-module-friendly object_class_by_name(). While there are no modularized user-creatable classes right now, there is no real difference between them and character devices (which do allow modularization). This patch could be left out if desired. Paolo Paolo Bonzini (5): qom: remove unused function qom: use object_new_with_class when possible qom: centralize module-loading functionality qom: let object_new use a module if the type is not present qom: allow user-creatable classes to be in modules include/qom/object.h | 8 ----- hw/core/qdev.c | 21 ++--------- qom/object.c | 80 +++++++++++++++++++---------------------- qom/object_interfaces.c | 4 +-- qom/qom-qmp-cmds.c | 4 +-- 5 files changed, 43 insertions(+), 74 deletions(-) -- 2.47.0
