On 10/7/2026 3:54 PM, Yonggang Luo wrote: > On Thu, Oct 8, 2026 at 6:31 AM Pierrick Bouvier > <[email protected]> wrote: >> >> On 10/7/2026 1:50 PM, Yonggang Luo wrote: >>> On Thu, Oct 8, 2026 at 4:29 AM Pierrick Bouvier >>> <[email protected]> wrote: >>>> >>>> On 10/7/2026 4:48 AM, Yonggang Luo wrote: >>>>> Register target definitions through constructors instead of >>>>> MODULE_INIT_TARGET_INFO, making target_info_list() and target_info() >>>>> available on entry to main(), without explicit initialization or a >>>>> call to module_call_init(MODULE_INIT_QOM). >>>>> >>>>> Keep the target list sorted by target_arch and default to its first >>>>> entry. Provide an unknown TargetInfo fallback for target-independent >>>>> tools such as qemu-img and unit tests that link no target-info-def.c >>>>> objects. >>>>> >>>>> Remove the obsolete QOM target-info registration infrastructure and >>>>> update the multi-target test to inspect target information before >>>>> initializing QOM. >>>>> >>>>> Signed-off-by: Yonggang Luo <[email protected]> >>>>> --- >>>>> include/qemu/module.h | 1 - >>>>> include/qemu/target-info-def.h | 56 +++++++++++++++++++++++++++--- >>>>> include/qemu/target-info-init.h | 53 ---------------------------- >>>>> include/qemu/target-info-qom.h | 31 ----------------- >>>>> include/qemu/target-info.h | 9 +++++ >>>>> meson.build | 6 ++-- >>>>> system/vl.c | 4 --- >>>>> target-info-def.c | 1 - >>>>> target-info-qom.c | 60 -------------------------------- >>>>> target-info.c | 61 ++++++++++++++++++++++++++++++++- >>>>> tests/qtest/fuzz/fuzz.c | 3 -- >>>>> tests/unit/test-multi-target.c | 12 +++---- >>>>> 12 files changed, 129 insertions(+), 168 deletions(-) >>>>> delete mode 100644 include/qemu/target-info-init.h >>>>> delete mode 100644 include/qemu/target-info-qom.h >>>>> delete mode 100644 target-info-qom.c >>>>> >>>> >>>> This approach (custom list based) was considered before implementing >>>> things with QOM Types. The rationale I followed was that if everything >>>> is in QOM, we might better follow that for consistency sake. >>>> Yes, the compromise if that we need an extra init step, but it was not a >>>> problem to add it. >>> I have issue to add the init step for unit-tests, and hard to write the >>> -target >>> parse procedure and get it right. Not means this won't work. but for >>> me, too much >>> coupled. >>> >> >> We already have such a test upstream: >> https://gitlab.com/qemu-project/qemu/-/blob/master/tests/unit/test-multi-target.c#L35 >> >> The init sequence is quite straightforward: >> >> ``` >> /* initialize target types, and only them */ >> module_call_init(MODULE_INIT_TARGET_INFO); >> >> /* we can get the list if we want, for -target or any other purpose */ >> g_autoptr(GSList) targets = object_class_get_list(TYPE_TARGET_INFO, false); >> >> /* set the global target info from any element in this list */ >> TargetInfo* ti = ...; >> target_info_qom_set_target_info(ti); >> >> /* register rest of QOM types */ >> module_call_init(MODULE_INIT_QOM); >> ``` >> >> It works fine to implement -target (if we would like to do it), since I >> implemented it myself. That was also my initial motivation by the way. >> >> Also, I appreciate that target-info is NULL by default, it crashes >> loudly when it has not been set, and make it easy to find who depends on it. >> >>> If we treat target_info as a QOM, but QOM needs target_info to set >>> up(is_avaible). That makes >>> the init sequence too much of a burden. >>> >> >> See sequence above, the solution is to initialize TARGET_INFO first, >> before the rest of QOM. You end up with the same result than with a >> statically initialized list. >> >>> >>> is_available is depends on target_arch >>> And before this patch, target_arch depends on QOM, pulls user/softmmu >>> because >>> target_info_init. By moving target-info to be a custom list based, we >>> can decouple >>> target-info from qom/softmmu/user. and target-info will always >>> available once "main(argv, argc)" is entered. We also have the >>> advantage of doing all sorts >>> of tests against it. >>> >> >> Which kind of tests are you trying to add? >> >> For now, the exact list of places where we need to do this initialize >> target dance are: >> - system/vl.c: module_call_init(MODULE_INIT_TARGET_INFO); >> - tests/qtest/fuzz/fuzz.c: module_call_init(MODULE_INIT_TARGET_INFO); >> - tests/unit/test-multi-target.c: >> module_call_init(MODULE_INIT_TARGET_INFO); >> >> If we want more tests, I'm totally ok to move this init code to >> target-info.c, and replace call sites if needed. >> >>> >>> Tools such as qemu-img and unit tests may link target-info.c without any >>> target-info-def.c objects. Their target list remains empty, so use this >>> fallback. >>> >> >> Why should this tool get access to target list? qemu-img deals with disk >> images, and is unrelated to targets. >> >>> >>> static TypeImpl *type_register_internal(const TypeInfo *info) >>> { >>> TypeImpl *ti; >>> >>> if (!type_name_is_valid(info->name)) { >>> fprintf(stderr, "Registering '%s' with illegal type name\n", >>> info->name); >>> abort(); >>> } >>> >>> if (info->is_available && !info->is_available()) { >>> return NULL; >>> } >>> >>> ti = type_new(info); >>> >>> type_table_add(ti); >>> return ti; >>> } >>> >>>> >>>> Is there another good value this list approach brings compared to what >>>> exists? > > Sorry, I have to wait for your work to be done first. > I have too many patches depending on this, and it seems hard to > convince you. Let's just keep it as is. > Maybe you can work them out in an easier way. >
I quit the effort of upstreaming a qemu-system binary some time ago, because it was not easy to get a consensus on what the new binary should be, and I'm happy you took the relay there. I try my best to help on the issues you bring, some of them being interesting problems that we need to solve. Thanks to your work and persistence, it seems like conversation is starting to converge towards something: qemu-system with all devices/machines/cpus available. It's not what I had in my mind originally, but I'm happy to see progress on this, and open to accept this alternative! > My work is here. > https://gitlab.com/lygstate-qemu/qemu/-/tree/combined-binary-multi-targets?ref_type=heads > I am afraid of posting 300 pathces into threads to flood it(and > disturbing yours). So I'll wait for your work first. and resolving > conflicts later, that's really time-consuming. > It's indeed not possible to send 300 patches and expect this to work, whether it's on this mailing list, or any software forge also. It's also not possible to send a link, and expect anyone to take a look at the 373 commits sitting it on top of master. My name is not Claude. Instead, humans have to progress step by step, based on feedback. Yes it takes time and it can be frustrating. And yes, I've been there (and frustrated) also, I feel sorry for you. At the moment, if we want to make it move on, we need to focus on one single thing: "How to document/specify which targets a machine support". > I did many explanations before. seems my explanation is too bad and > not to give a clean picture for you, let's delay these first. > If I can suggest something politely here, IMHO, alternating between genuinely human written messages, and AI content sent as it is on email or commit messages is not helping on the receiver side. I would prefer anytime to deal with imperfect english (mine is imperfect too, I'm not a native speaker neither), compared to read what Claude/GPT/Deepseek generated that was pasted as it is. I understand it's a good tool for helping on the language side, and that's ok to fix grammar and sentence structure. But asking "Please generate a summary from those email threads and explain what the current series is doing", and paste this is doomed to fail. It also has a very detrimental side effect: it makes me start to wonder where the code is coming from also. Especially when seeing boilerplates with lengthy comments written in perfect english. My 2 cents is, use AI if you want/need, but make sure the result has this *human* touch. > I only sent these 8 patches for easier review. because too many > patches won't be accepted either. > This series is useful, thanks to your answer on last patch, I finally see where you're headed. I'll answer there to keep this moving forward. Regards, Pierrick
