Eric Blake <eblake@xxxxxxxxxx> writes: > On 3/28/19 3:06 PM, Eric Blake wrote: >> On 3/28/19 2:32 PM, Markus Armbruster wrote: >>> Markus Armbruster <armbru@xxxxxxxxxx> writes: >>>> Pavel Hrdina <phrdina@xxxxxxxxxx> 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[]. >> >> 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. >> 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 <kraxel@xxxxxxxxxx> 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 <kraxel@xxxxxxxxxx> 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
