On Mon, May 18, 2020 at 11:26:50AM +0100, Daniel P. Berrangé wrote:
On Mon, May 18, 2020 at 12:16:28PM +0200, Gerd Hoffmann wrote:
> On Fri, May 15, 2020 at 05:08:23PM +0200, Ján Tomko wrote:
> > On a Friday in 2020, Gerd Hoffmann wrote:
> > > Add deprecation message to the audio init function.
> > >
> > > Factor out audio initialization and call that from
> > > both audio init and realize, so setting audiodev via
> > > -global is enough to properly initialize pcspk.
> > >
> > > Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
> > > ---
> > > hw/audio/pcspk.c | 24 +++++++++++++++++++++---
> > > 1 file changed, 21 insertions(+), 3 deletions(-)
> > >
> > > @@ -236,9 +245,18 @@ static const TypeInfo pcspk_info = {
> > > .class_init = pcspk_class_initfn,
> > > };
> > >
> > > +static int pcspk_audio_init_soundhw(ISABus *bus)
> > > +{
> > > + PCSpkState *s = pcspk_state;
> > > +
> > > + warn_report("'-soundhw pcspk' is deprecated, "
> > > + "please set a backend using '-global
isa-pcspk.audiodev=<name>' instead");
> > > + return pcspk_audio_init(s);
> >
> > -soundhw pcspk is the only soundhw device present in libvirt git.
> >
> > Is there a way to probe for this change via QMP?
>
> Oops. I'm surprised libvirt actually supports pcspk.
>
> There is no way to see that in qmp, and I can't think of an easy way
> to add that. Does libvirt check for command line switches still?
> So it could see -soundhw going away if that happens?
IIUC, instead of probing for whether -soundhw is deprecated, it should
be suffiicent for us to probe if "isa-pcspk.audiodev" exists. Assuming
we always use isa-pcspk.audiodev if it exists, then we'll trivially
avoid using the -soundhw arg.
It's not that easy unfortunately. We have .audiodev for a few releases
already. But just setting that isn't enough to initialize pcspk in
current qemu, "-soundhw pcspk" is still needed ...
I'm looking at how to initialize onboard audio devices currently, maybe
the best way to handle that is to do it flash-style with machine
properties (i.e have a pc.pcslk alias for pcspk.audiodev, simliar to
pc.flash0 being an alias for pflash.drive). That'll be better that
-global and it'll also be visible in QOM.
Initialization order looks tricky though. I'd have to create pcspk
early, simliar to flash, in pc_machine_initfn(). Problem is I don't
have a isa bus yet at that point (flash is sysbus and doesn't have this
problem). I'm open to suggestions hiow do deal with that best.
take care,
Gerd