Pavel Hrdina <phrd...@redhat.com> writes: > On Fri, Mar 29, 2019 at 08:19:55AM +0100, Markus Armbruster wrote: >> Eric Blake <ebl...@redhat.com> writes: >> >> > On 3/28/19 3:06 PM, Eric Blake wrote: >> >> On 3/28/19 2:32 PM, Markus Armbruster wrote: >> >>> Markus Armbruster <arm...@redhat.com> writes: >> >>>> Pavel Hrdina <phrd...@redhat.com> writes: >> >> >> >>>>> I'm glad that this is merged now and I wanted to start working on >> >>>>> libvirt patches, but there is one big issue with this command, >> >>>>> it's not introspectable by query-command-line-options. >> [...] >> >>>>> Adding Markus to CC so we can figure out how to wire up the >> >>>>> introspection for such command line options. >> [...] >> >>> Command line options are actually defined in qemu-options.hx, which gets >> >>> massaged into qemu_options[]. For each option, qemu_options[] gives us >> >>> the option name (without leading '-'), and whether the option takes an >> >>> argument. >> >>> >> >>> This is less information per option than q-c-l-o provides now. Can we >> >>> add it to its output anyway without confusing existing users? >> [...] >> >>> Alternatives: >> [...] >> >>> 5. Screw it, create a new query command to return just the information >> >>> from qemu_options[]. > > Hi Markus, > > Thanks for looking into this issue, it would be perfect to solve it > before QEMU 4.0 is released.
To be honest, I wouldn't bet my own money on 4.0 at this point. I understand why you're eager to switch libvirt to -audiodev, it's such a massive improvement over the traditional mess. But is it urgent? Does it fix bugs? Does it add features? Sure it can't wait for 4.1? >> >> Alternative 6: >> >> >> >> Don't worry about patching q-c-l-o, but instead patch query-qemu-features: >> >> >> >> https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg07584.html >> >> >> >> Add a new feature: audiodev-command-line >> >> >> >> That addition becomes both introspectible (since query-qemu-features >> >> options are introspectible regardless of their runtime state) and >> >> queryable (not that this feature needs runtime queries, but others might). >> >> What is query-qemu-features about? Is it about QMP, or is it a grab-bag >> of ad hoc flags? To be discussed further in the thread you quoted. > > From what I was reading the query-qemu-features should be used for > features that are not introspectable from qmp-schema or by other means. > Yes, the 'audiodev' is not currently in the schema but in order to have > reasonable introspection we should not report only that the command line > option is present, we should report also all parameters of that option. Yes. I feel pressing query-qemu-features into service here would border on abuse. Of course, abuse can be less bad than doing nothing. I depends on the particular case. >> >> And, since we're already proposing query-qemu-features for 4.0 for >> >> another reason, making it 2 reasons instead of 1 feels like extra >> >> justification for getting it done in a timely manner. >> > >> > And answering myself after a bit more thought - the question is not just >> > about "can we use the command line instead of envvars", but one step >> > further of "once we are using the command line, what works in this >> > release as opposed to added in later releases". So we still want >> > introspection to land on the full QAPI types for audiodev, even if, for >> > 4.0, we can't actually use QMP to change them. This means we at least >> > need a QMP command that references the QAPI types (even if the command >> > is named "x-audiodev-dummy" and always fails), so that the types at >> > least make it into the introspection output, coupled with the >> > query-qemu-features bit to state that even when we remove the hack of >> > the x-audiodev-dummy command later, we can still use audiodev and scrape >> > enough out of introspection for our needs. >> >> Alternative 7: a hack to make QAPI type Audiodev visible in >> query-qmp-schema. >> >> query-qmp-schema shows exactly the types reachable from QMP commands and >> events. >> >> You can't look up a type by name there, you have to start at a command >> or an event. We'd have to create a suitable dummy. Recent precedence: >> >> commit e1ca8f7e1915496148f6e0ce1f7c2309af013312 >> Author: Gerd Hoffmann <kra...@redhat.com> >> Date: Thu Nov 22 08:16:13 2018 +0100 >> >> qapi: add query-display-options command >> >> Add query-display-options command, which allows querying the qemu >> display configuration. This isn't particularly useful, except it >> exposes QAPI type DisplayOptions in query-qmp-schema, so that libvirt >> can discover recently added -display parameter rendernode (commit >> d4dc4ab133b). Works around lack of sufficiently powerful command >> line >> introspection. >> >> Signed-off-by: Gerd Hoffmann <kra...@redhat.com> >> >> As much as I dislike such hacks, they can be the least bad option. >> >> Compare alternative 7. to 5.: 7. exposes complete syntactic information >> just for -audiodev, 5. exposes rudimentary syntactic information for all >> options. There's room for both. Doesn't mean we should do both, of >> course. > > My guess is that QEMU will introduce more command line parameters which > will be able to consume both options and JSON. I think so, too. > Currently we have > 'blockdev', 'display' and 'audiodev' where 'blockdev' is present in the > output of 'query-qmp-schema' through the 'blockdev-add' qmp-command and > for 'display' we have dedicated command. > > I would see it like alternative 7. can be used now to fix the issue > present in QEMU 4.0 that we cannot introspect 'audiodev' option and > figure out how to implement some generic qmp-command that would report > command line options and all parameters. I figure we need to come up with a plan for incremental command line QAPIfication beyond the ad hoc ways we've used so far, complete with schema introspection. This should obsolete any QMP commands that exist only to expose bits of the command line QAPI schema in the QMP QAPI schema. I think the commands should be deprecated then.
