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. 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 :|
