Back to Paolo's example of "a compat property will be set on a device
*after* the class's post_init callback has run". I think the behavior of
compat property is applied after the class's post_init callback is also
what we want. If reversing the order, then compat prop can be
overwritten by subclass's post_init callback, and doesn't it fail the
purpose of compat prop?
I wrote the patch because of a latent issue with TDX. The issue was roughly that a compat property was overwriting the TDX-specific modifications to CPUID. I think this case shows that you *do* want the subclass to overwrite the compat property—of course the subclass code must be aware that compat properties exist and limit changes appropriately.
In general I don't see how the reverse order makes sense: the subclass knows what the superclass does, so it can do the right thing if it runs last; but the superclass cannot know what all of its subclasses do in post_init, so it makes less sense to run it last.
Paolo
So I think we might revert this patch, and document clearly the reverse
order of .post_instance_init() callback.
> X86 CPUs have the issue (e.g., "vendor" doesn't work) now because
> they - as leaf class, don't care about the property values of
> superclass - the DeviceState. If a property is just for initialization,
> like "vendor", it should be placed in the instance_init() instead of
> instance_post_init().
>
> In addition, if other places handle it similarly, the device's
> post_init seems pointless. :-(
>
> Thanks,
> Zhao
>