> +impl ClassInitImpl<PL011Class> for PL011State {
> + fn class_init(klass: &mut PL011Class) {
> + klass.device_id = DeviceId::ARM;
> + <Self as ClassInitImpl<SysBusDeviceClass>>::class_init(&mut
> klass.parent_class);
This seems a bit of a conflict with the C version of QOM semantics. In C,
class_init is registered in TypeInfo, and then the QOM code will
automatically call the parent's class_init without needing to explicitly
call the parent's in the child's class_init.
However, SysBusDevice (and Device) is a bit different. Its TypeInfo is
registered on the C side, and the class_init method on the Rust side is not
actually a real QOM class_init (because it is not registered on the Rust
side).
Therefore, the call here seems valid from the code logic's perspective.
But, when there is deeper class inheritance, it seems impossible to
prevent class_init from being called both by the C side's QOM code and by
this kind of recursive case on the Rust side.
So, for devices like SysBusDevice that are registered on the C side,
should we not implement class_init and also not call it explicitly?
Or should we distinguish between two different usages of class_init? One
is registered in TypeInfo (only as a callback in rust_class_init) - perhaps
rename it as qom_class_init, and the other is used as a helper for Rust-side
calls (similar to the recursive usage here) - maybe rename it as
class_inter_init.
> + }
> +}
