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