On Mon, May 03, 2021 at 13:21:47 -0500, Eric Blake wrote:
> On 4/29/21 4:59 AM, Markus Armbruster wrote:
[...]
> > qemu-img backing file without format (since 5.1)
> >
> >
> > The use of ``qemu-img create``, ``qemu-img rebase``, or
On Tue, May 4, 2021 at 1:13 AM Paolo Bonzini wrote:
>
> On 03/05/21 09:12, Alistair Francis wrote:
> >> deprecated.rst is mainly thought for the things that only have been marked
> >> as deprecated, but not changed yet. Once it's done, the items normally get
> >> moved to
On 4/29/21 4:59 AM, Markus Armbruster wrote:
> If you're cc'ed, you added a section to docs/system/deprecated.rst that
> is old enough to permit removal. This is *not* a demand to remove, it's
> a polite request to consider whether the time for removal has come.
> Extra points for telling us in a
On 03/05/21 09:12, Alistair Francis wrote:
deprecated.rst is mainly thought for the things that only have been marked
as deprecated, but not changed yet. Once it's done, the items normally get
moved to docs/system/removed-features.rst instead.
Too easy, I'll move it there instead.
Can you
On 29/04/21 14:40, Gerd Hoffmann wrote:
In other words you would do something like -audiohw
,model=xxx and it gets desugared automatically to either
-audiodev ,id=foo -device devname,audiodev=xxx
or
-audiodev ,id=foo -M propname=foo
Suggestions how to do that in a clean way?
Given
On 4/29/21 11:59 AM, Markus Armbruster wrote:
> If you're cc'ed, you added a section to docs/system/deprecated.rst that
> is old enough to permit removal. This is *not* a demand to remove, it's
> a polite request to consider whether the time for removal has come.
> Extra points for telling us in
Peter Maydell writes:
> On Thu, 29 Apr 2021 at 12:19, Thomas Huth wrote:
>>
>> On 29/04/2021 11.59, Markus Armbruster wrote:
>> > If you're cc'ed, you added a section to docs/system/deprecated.rst that
>> > is old enough to permit removal. This is *not* a demand to remove, it's
>> > a polite
On Mon, May 3, 2021 at 2:49 PM Thomas Huth wrote:
>
> On 03/05/2021 03.41, Alistair Francis wrote:
> > On Thu, Apr 29, 2021 at 8:00 PM Markus Armbruster wrote:
> >>
> >> If you're cc'ed, you added a section to docs/system/deprecated.rst that
> >> is old enough to permit removal. This is *not* a
On 03/05/2021 03.41, Alistair Francis wrote:
On Thu, Apr 29, 2021 at 8:00 PM Markus Armbruster wrote:
If you're cc'ed, you added a section to docs/system/deprecated.rst that
is old enough to permit removal. This is *not* a demand to remove, it's
a polite request to consider whether the time
On Thu, Apr 29, 2021 at 8:00 PM Markus Armbruster wrote:
>
> If you're cc'ed, you added a section to docs/system/deprecated.rst that
> is old enough to permit removal. This is *not* a demand to remove, it's
> a polite request to consider whether the time for removal has come.
> Extra points for
Gerd Hoffmann writes:
> Hi,
>
>> IOW, if QEMU was to be conservative, you can drop all env vars except
>> the main QEMU_AUDIODRIVER.
>
> As already mentioned above I want drop all legacy audio bits at once.
>
> Leaving in the compatibility bits in for one or two more releases is
> IMHO better
On Thu, Apr 29, 2021 at 05:05:35PM +0200, Philippe Mathieu-Daudé wrote:
> On 4/29/21 3:46 PM, Gerd Hoffmann wrote:
>
> > Hmm. Not so easy I suspect. While most sound cards map to a single
> > device there are exceptions. pcspk is build-in and hda is two devices.
>
> What do you mean by "pcspk
Philippe Mathieu-Daudé writes:
> On 4/29/21 3:46 PM, Gerd Hoffmann wrote:
>
>> Hmm. Not so easy I suspect. While most sound cards map to a single
>> device there are exceptions. pcspk is build-in and hda is two devices.
>
> What do you mean by "pcspk is build-in"?
>
> Do you mean "the 'pcspk'
Daniel P. Berrangé writes:
> On Thu, Apr 29, 2021 at 11:59:41AM +0200, Markus Armbruster wrote:
>> Myself, but I only documented it; it's actually Kevin Wolf:
>>
>> ``blockdev-open-tray``, ``blockdev-close-tray`` argument ``device``
>> (since 2.8.0)
>>
>>
On Thu, 2021-04-29 at 11:59 +0200, Markus Armbruster wrote:
> If you're cc'ed, you added a section to docs/system/deprecated.rst
> that
> is old enough to permit removal. This is *not* a demand to remove,
> it's
> a polite request to consider whether the time for removal has come.
> Extra points
+Jiri, +Daniel, +Igor
On Thu, Apr 29, 2021 at 11:59:41AM +0200, Markus Armbruster wrote:
[...]
> I'm not sure there's anything to remove here, but anyway, Peter Maydell:
>
This one is mine.
There's no code to remove, but the intention is to eventually
change default_cpu_version to
On 4/29/21 3:46 PM, Gerd Hoffmann wrote:
> Hmm. Not so easy I suspect. While most sound cards map to a single
> device there are exceptions. pcspk is build-in and hda is two devices.
What do you mean by "pcspk is build-in"?
Do you mean "the 'pcspk' audiodev is build in the 8254 PIT device"?
On Thu, Apr 29, 2021 at 11:59:41AM +0200, Markus Armbruster wrote:
> Stefan Hajnoczi:
>
> ``-device virtio-blk,scsi=on|off`` (since 5.0.0)
>
>
> The virtio-blk SCSI passthrough feature is a legacy VIRTIO feature.
> VIRTIO 1.0
>
Hi,
> Another option might be that you just nest things:
>
> { 'struct': 'AudioConfig',
> 'data': {
> 'model': 'AudioDevice',
> 'backend': 'Audiodev' } }
>
> Possibly instead of 'model' on the top level, you'll actually want to
> nest there, too, and accept device properties.
Am 29.04.2021 um 14:40 hat Gerd Hoffmann geschrieben:
> Hi,
>
> > For this to go away, I'd rather have something like the -nic option that
> > provides an easy way to set up the front end and back end.
> >
> > In other words you would do something like -audiohw
> > ,model=xxx and it gets
Hi,
> For this to go away, I'd rather have something like the -nic option that
> provides an easy way to set up the front end and back end.
>
> In other words you would do something like -audiohw
> ,model=xxx and it gets desugared automatically to either
>
>-audiodev ,id=foo -device
On Thu, 29 Apr 2021 at 12:19, Thomas Huth wrote:
>
> On 29/04/2021 11.59, Markus Armbruster wrote:
> > If you're cc'ed, you added a section to docs/system/deprecated.rst that
> > is old enough to permit removal. This is *not* a demand to remove, it's
> > a polite request to consider whether the
On 29/04/2021 11.59, Markus Armbruster wrote:
If you're cc'ed, you added a section to docs/system/deprecated.rst that
is old enough to permit removal. This is *not* a demand to remove, it's
a polite request to consider whether the time for removal has come.
Extra points for telling us in a
On 29/04/21 11:59, Markus Armbruster wrote:
Gerd Hoffmann:
Creating sound card devices using ``-soundhw`` (since 5.1)
''
Sound card devices should be created using ``-device`` instead. The
names are the same for most
On 29/04/21 12:35, Daniel P. Berrangé wrote:
Note the QEMU since has been ready since 4.0, in April 2019 so 2 years.
We dropped the ball on getting this implemented in libvirt, since we
had almost no config options for sound at all in libvirt. We had just
hardcoded 3 sound backends based on the
Hi,
> IOW, if QEMU was to be conservative, you can drop all env vars except
> the main QEMU_AUDIODRIVER.
As already mentioned above I want drop all legacy audio bits at once.
Leaving in the compatibility bits in for one or two more releases is
IMHO better than removing it partly now and the
On Thu, Apr 29, 2021 at 11:29:42AM +0100, Peter Maydell wrote:
> On Thu, 29 Apr 2021 at 11:28, Daniel P. Berrangé wrote:
> >
> > On Thu, Apr 29, 2021 at 12:18:42PM +0200, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since
> > > >
On Thu, Apr 29, 2021 at 11:59:41AM +0200, Markus Armbruster wrote:
> Myself, but I only documented it; it's actually Kevin Wolf:
>
> ``blockdev-open-tray``, ``blockdev-close-tray`` argument ``device``
> (since 2.8.0)
>
>
On Thu, 29 Apr 2021 at 11:28, Daniel P. Berrangé wrote:
>
> On Thu, Apr 29, 2021 at 12:18:42PM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
> > > Creating sound card devices and vnc without ``audiodev=`` property
>
On Thu, 29 Apr 2021 at 11:02, Markus Armbruster wrote:
>
> If you're cc'ed, you added a section to docs/system/deprecated.rst that
> is old enough to permit removal. This is *not* a demand to remove, it's
> a polite request to consider whether the time for removal has come.
> Extra points for
On Thu, Apr 29, 2021 at 12:18:42PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
> > Creating sound card devices and vnc without ``audiodev=`` property
> > (since 4.2)
> > Creating sound card devices using ``-soundhw``
Hi,
> ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
> Creating sound card devices and vnc without ``audiodev=`` property (since
> 4.2)
> Creating sound card devices using ``-soundhw`` (since 5.1)
I think these three should be dropped together, to minimize
If you're cc'ed, you added a section to docs/system/deprecated.rst that
is old enough to permit removal. This is *not* a demand to remove, it's
a polite request to consider whether the time for removal has come.
Extra points for telling us in a reply. "We should remove, but I can't
do it myself
33 matches
Mail list logo
