On 5/8/2026 9:10 AM, Daniel P. Berrangé wrote: > On Tue, May 05, 2026 at 03:48:20PM -0700, Pierrick Bouvier wrote: >> We are getting close to be able to link several targets in a single QEMU >> system >> binary, and the last obstacle on the road is to embed several TargetInfo in >> the >> same binary. The end result of this series is to have a single definition for >> target_info symbol. >> >> This series adds TargetInfo types in QOM, and retrieve them dynamically(). At >> the moment, we don't deal yet with multiple TargetInfo selection, but install >> all that is needed to be able to do it easily. >> >> Because TargetInfo data is set through class_init, it creates an issue at >> startup, where we may try to instantiate additional (unrelated) types just to >> retrieve the list of "target-info-X" types. Those other types class_init may >> be >> using target information, to add target specific properties for instance. >> This issue has been fixed by adding a new >> object_class_get_list_by_name_prefix >> that does not force instantiation of all QOM types, but only those matching a >> specific pattern. This way, we first initialize and retrieve target-info >> types >> before others. >> >> An alternative would be to leave all this out of QOM, and use startup >> initializer to add them in a single list. However, because all the >> single-binary >> work has been using QOM where possible, it would be really sad to not use it >> for >> this final step. Comments are welcome! >> >> Finally, sticking to our promise not create a special "single-binary >> configuration", the goal is to use the *exact* same codepath for normal >> binaries >> also. It means that even for existing system binaries, the goal will be to >> use >> QOM to retrieve current target, even if there is only one. >> >> v4 >> -- >> >> - Revert to v2 MODULE_INIT_TARGET_INFO as Daniel didn't comment on issues >> about >> about MODULE_INIT_QOM_EARLY. > > Sorry for not responding to that, other things got in the way > this week. >
No worries, that's a good lesson for me about not interpreting not having answer as a lack of interest when someone is active on other threads. > For clarity, I withdraw my objections from v2. Having seen how > my suggested approadch in v3 looked, I think you were correct > all along. > The important is that we explored this path and its limitations. > With regards, > Daniel Thanks Daniel, Pierrick
