[libvirt] [Qemu-devel] [PULL 04/14] audio: -audiodev command line option basic implementation
Markus Armbruster
armbru at redhat.com
Fri Mar 29 13:58:47 UTC 2019
Pavel Hrdina <phrdina at redhat.com> writes:
> On Fri, Mar 29, 2019 at 11:12:55AM +0100, Markus Armbruster wrote:
>> Pavel Hrdina <phrdina at redhat.com> writes:
>>
>> > On Fri, Mar 29, 2019 at 08:19:55AM +0100, Markus Armbruster wrote:
>> >> Eric Blake <eblake at 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 <armbru at redhat.com> writes:
>> >> >>>> Pavel Hrdina <phrdina at 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?
>
> It's definitely not urgent, the audio situation is broken the whole
> time so we can wait for 4.1. It will help us to fix some bugs but
> nothing critical.
Let's aim for something decent in 4.1. Perhaps alternative 5. Perhaps
even something that can grow into real command line introspection.
Perhaps both.
More information about the libvir-list
mailing list