Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > Il 28/01/2014 10:36, Markus Armbruster ha scritto: >> I think the data you can usefully collect with this approach is >> approximately the data getopt_long()[*] gets: list of named command line >> options, and whether they take an argument. >> >> You can use this data to fill in options not covered by QemuOpts. This >> is a definite improvement. >> >> It still falls short of fully solving the command line introspection >> problem. >> >> However, I'm not into rejecting imperfect incremental improvements we >> can have now in favor of perfect solutions we can maybe have some day. >> Go right ahead with your incremental improvement! > > It depends. If we can agree on the following: > > (a) do not add non-QemuOpts options (we haven't for a while) That would mean we can't ever add an option that doesn't take an argument again. However, we need to somehow stuff those into QemuOpts anyway, so -readconfig / -writeconfig can cover them. > (b) document the QemuOpts schema for -acpitable, -smbios, -netdev, > -net. These options validate the options with OptsVisitor, so we could > do without QemuOpts schema, but we know the schema won't bitrot > because we never remove suboptions. -device? > (c) do not add any more QemuOpts options without a schema, and use > -object instead. > > Then: > > (a) there is no need to cover non-QemuOpts options in > query-command-line-options. libvirt can treat them as crystallized. Some options are undef #ifdef. That's actually a good idea, because it permits finding out which options are available via command line introspection. Now, what if a non-QemuOpts option is under #ifdef? I haven't checked... Even if there isn't one now, are we ready to give up the ability to do that for good? > (b) documenting the schemata is not harder than what Amos proposed. > > (c) schema inspection for objects remains a problem, but one that we > need to solve anyway so it doesn't affect query-command-line-options. As long as we don't have such schema inspection, I'm rather reluctant to reject alternative means to solve problems people have *now*. > Do you agree? It depends :) -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list