On 18.02.26 13:50, Daniel P. Berrangé wrote:
On Wed, Feb 18, 2026 at 01:52:06PM +0500, Sergei Heifetz wrote:
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.
IMHO "static analysers complain" is way too weak a justification
for taking on this work. Code analysers are always incredibly noisy
and reporting complaints about things that are not worth the cost
of addressing.
Still we consider such complains as a good reason to drop extra code from
our production build. If we have to spend some time handling Coverity
complains, why not just drop extra parts we don't use, so that static
analyzers will never disturb us about these parts since removal?
Regardless static analyzers, I think it's always good to have a possibility
to not build for production the code which you don't need and don't want to
understand and support.
--
Best regards,
Vladimir
