Thomas Huth <th...@redhat.com> writes: > On 15/11/2022 08.53, Markus Armbruster wrote: >> Thomas Huth <th...@redhat.com> writes: >> >>> On 11/11/2022 15.53, Markus Armbruster wrote: >>>> Thomas Huth <th...@redhat.com> writes: >>>> >>>>> The "query-command-line-options" command uses a hand-crafted list >>>>> of options that should be returned for the "machine" parameter. >>>>> This is pretty much out of sync with reality, for example settings >>>>> like "kvm_shadow_mem" or "accel" are not parameters for the machine >>>>> anymore. Also, there is no distinction between the targets here, so >>>>> e.g. the s390x-specific values like "loadparm" in this list also >>>>> show up with the other targets like x86_64. >>>>> >>>>> Let's fix this now by geting rid of the hand-crafted list and by >>>>> querying the properties of the machine classes instead to assemble >>>>> the list. >>>> >>>> Do we know what uses this command, and how these users are >>>> inconvenienced by the flaw you're fixing? >>>> I'm asking because the command is pretty much out of sync with reality >>>> by (mis-)design. >>> >>> libvirt apparently queries this data (see the various >>> tests/qemucapabilitiesdata/*.replies files in their repository), but since >>> it's so much out-of-sync with reality, it's not of a big use there yet. >>> >>> See for example here: >>> >>> https://lists.gnu.org/archive/html/qemu-devel/2021-12/msg00581.html >>> >>> If we finally fix this problem with "query-command-line-options" in QEMU, >>> it should be much easier to deprecate -no-hpet in QEMU, too. >> >> For a value of "fix". While we can fix certain concrete issues with >> q-c-l-o, which may be wortwhile, the overarching issue is (in my >> opinion) unfixable: it can only tell us about QemuOpts. >> >> QemuOpts is only part of the truth. Last time I checked, it worked for >> one out of five CLI options. > > Well, that's another problem. For this patch here, can we please focus on > getting rid of that stupid hard-coded and outdated list in our source code? > Or do you have something better almost ready that will replace this stuff in > the very near future?
I'm not objecting to fixing "concrete issues with q-c-l-o, which may be worthwhile", such as this patch, as long as something actually makes use of the fixes, now or in the immediate future.
