[prev in list] [next in list] [prev in thread] [next in thread] 

List:       libvir-list
Subject:    Re: [libvirt] [Qemu-devel] [PULL 04/14] audio: -audiodev command line option basic implementation
From:       Markus Armbruster <armbru () redhat ! com>
Date:       2019-03-29 13:58:47
Message-ID: 87bm1tixyg.fsf () dusky ! pond ! sub ! org
[Download RAW message or body]

Pavel Hrdina <phrdina@redhat.com> writes:

> On Fri, Mar 29, 2019 at 11:12:55AM +0100, Markus Armbruster wrote:
>> Pavel Hrdina <phrdina@redhat.com> writes:
>> 
>> > On Fri, Mar 29, 2019 at 08:19:55AM +0100, Markus Armbruster wrote:
>> >> Eric Blake <eblake@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@redhat.com> writes:
>> >> >>>> Pavel Hrdina <phrdina@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.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[prev in list] [next in list] [prev in thread] [next in thread]