On 10/25/24 10:59, Zhao Liu wrote:
I want to see how general this macro could be, so I checked current type_init() cases for TypeInfo. In most cases, only type_register_static() is called directly in the init_fn() callback.
First of all, it's okay if the Rust code does not cover everything. But looking at your cases:
There are only two exceptions: 1. Some init_fn callbacks contain more complex validation or register logic. For example, in backends/hostmem-epc.c, sgx_epc_backed_info involves extra check before type_register_static(). static void register_types(void) { int fd = qemu_open_old("/dev/sgx_vepc", O_RDWR); if (fd >= 0) { close(fd); type_register_static(&sgx_epc_backed_info); } }
This one is okay to just change to type_register_static(), moving the /dev/sgx_vepc code to the "complete" callback.
And in hw/audio/intel-hda.c, there's extra pci_register_soundhw afer type_register_static(): static void intel_hda_register_types(void) { type_register_static(&hda_codec_bus_info); type_register_static(&intel_hda_info); type_register_static(&intel_hda_info_ich6); type_register_static(&intel_hda_info_ich9); type_register_static(&hda_codec_device_type_info); pci_register_soundhw("hda", "Intel HD Audio", intel_hda_and_codec_init); } The device can define a custom init_fn() for TypeInfo based on module_init!, but I wonder if the examples above are valid. Is it allowed to include other logic in init_fn()?
Yes, it is but it is also possible to use your own module_init! invocation outside #[derive(Object)].
2. Some init_fn callbacks use type_register() instead of type_register_static(). TypeImpl *type_register_static(const TypeInfo *info) { return type_register(info); } It seems that type_register() and type_register_static() are the same. I guess I could clean up one of them, right? (type_register() was added by your earlie commit 049cb3cfdac1 :-) ).
Yeah, you can! Paolo