On 2/17/26 15:14, Daniel P. Berrangé wrote:
On Tue, Feb 17, 2026 at 10:06:19AM +0000, Peter Maydell wrote:
On Tue, 17 Feb 2026 at 09:42, Paolo Bonzini <[email protected]> wrote:
On 2/17/26 10:31, Peter Maydell wrote:
On Tue, 17 Feb 2026 at 05:29, Sergei Heifetz <[email protected]> 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
In some production environments, static analysers are used as part of
broader security measures. If such an analyser reports a problem in an
unused part of the code, you can’t simply ignore it because it’s unused:
you either fix the issue (which is a strange thing to do for unused
code) or remove the unused part. This is a general point about why such
functionality may be useful for some users.
Other audio-specific reasons for having this option are already
described by Paolo:
https://mail.gnu.org/archive/html/qemu-devel/2026-02/msg04410.html.
