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 -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
