Re: [PATCH 1/8] audio: add `audio` build option for meson and Kconfig

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Feb 17, 2026 at 10:06:19AM +0000, Peter Maydell wrote:
> On Tue, 17 Feb 2026 at 09:42, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> > On 2/17/26 10:31, Peter Maydell wrote:
> > > On Tue, 17 Feb 2026 at 05:29, Sergei Heifetz <heifetz@yandex-team.com> wrote:
> > >>
> > >> This patch adds the `audio` option to meson_options.txt. It is
> > >> propagated into Kconfig as AUDIO. It is enabled by default.
> > >> The corresponding `--disable-audio` and `--enable-audio` options
> > >> for `configure` are also added.
> > >>
> > >> For now, this option does nothing. In subsequent patches, it will
> > >> gradually disable audio in different places. The final goal is to stop
> > >> building sources from `audio/` and `hw/audio/` and other audio-related
> > >> files (except for some stubs). Note that this intent is different from
> > >> `-audio none`, which mutes audio but still compiles the audio subsystem.
> > >
> > > Not building audio/ code makes sense, but do we really want to
> > > stop building hw/audio code ? That's the guest facing audio
> > > devices, and if for instance a machine type has an embedded
> > > sound device that would require us to stop compiling that
> > > machine. I think it would be very confusing for users if
> > > --disable-audio meant "we will silently not build half the
> > > Arm boards that have a pl041 in them".
> > >
> > > Maybe it would be better if "--disable-audio" meant "don't build
> > > the audio backends, and everything behaves as if the user
> > > passed -audio none" ?
> >
> > The problem is that "-audio none" uses a silent backend but still keeps
> > all the audio/ code around.  If you prefer to keep the Arm boards
> > around, the solution would be to disable the audio code in the
> > individual pl041 devices with "#ifdef CONFIG_AUDIO", so that the
> > "depends on AUDIO" for pl041 can be removed too.
> 
> This seems weird, though -- why would we put in a lot of ifdefs
> in every single audio device, when we could instead say "if you
> disable audio at build time what you get is something that presents
> the same API as the existing audio backends but does nothing" ?
>
> Also, I think we should be consistent here, not put ifdefs in
> some devices we think are "important" but skip it in others.

If we consider our security boundary guidance, none of these boards
with on-board audio frontends would be considered in scope for
security.

On arm, only the "virt" board is providing a secure deployment, and
that does not require this --disable-audio functionality.

The same applies broadly to other arch targets too, with perhaps the
only exception being the "PC speaker" on x86, and a "none" audio
backend should be sufficient there IMHO.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|