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.
Signed-off-by: Sergei Heifetz <heifetz@yandex-team.com>
---
Kconfig.host | 3 +++
configure | 4 ++++
meson.build | 3 +++
meson_options.txt | 3 +++
4 files changed, 13 insertions(+)
diff --git a/Kconfig.host b/Kconfig.host
index 933425c74b..ec129aa4fc 100644
--- a/Kconfig.host
+++ b/Kconfig.host
@@ -29,6 +29,9 @@ config IVSHMEM
config TPM
bool
+config AUDIO
+ bool
+
config FDT
bool
diff --git a/configure b/configure
index 4b61fd3bbf..ff391c79a1 100755
--- a/configure
+++ b/configure
@@ -762,6 +762,10 @@ for opt do
;;
--wasm64-32bit-address-limit)
;;
+ --enable-audio) meson_option_add -Daudio=true
+ ;;
+ --disable-audio) meson_option_add -Daudio=false
+ ;;
# everything else has the same name in configure and meson
--*) meson_option_parse "$opt" "$optarg"
;;
diff --git a/meson.build b/meson.build
index 8c6c0a9a32..69aa7cd189 100644
--- a/meson.build
+++ b/meson.build
@@ -68,6 +68,8 @@ foreach target : target_dirs
endforeach
have_user = have_linux_user or have_bsd_user
+audio_enabled = get_option('audio')
+
############
# Programs #
############
@@ -3244,6 +3246,7 @@ disassemblers = {
have_ivshmem = config_host_data.get('CONFIG_EVENTFD')
host_kconfig = \
(get_option('fuzzing') ? ['CONFIG_FUZZ=y'] : []) + \
+ (audio_enabled ? ['CONFIG_AUDIO=y'] : []) + \
(have_tpm ? ['CONFIG_TPM=y'] : []) + \
(pixman.found() ? ['CONFIG_PIXMAN=y'] : []) + \
(spice.found() ? ['CONFIG_SPICE=y'] : []) + \
diff --git a/meson_options.txt b/meson_options.txt
index 2836156257..172ed10ead 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -71,6 +71,9 @@ option('malloc_trim', type : 'feature', value : 'auto',
option('malloc', type : 'combo', choices : ['system', 'tcmalloc', 'jemalloc'],
value: 'system', description: 'choose memory allocator to use')
+option('audio', type: 'boolean', value: true,
+ description: 'Audio support')
+
option('kvm', type: 'feature', value: 'auto',
description: 'KVM acceleration support')
option('mshv', type: 'feature', value: 'auto',
--
2.34.1On 2/17/26 06:27, Sergei Heifetz 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.
>
> Signed-off-by: Sergei Heifetz <heifetz@yandex-team.com>
> ---
> Kconfig.host | 3 +++
> configure | 4 ++++
> meson.build | 3 +++
> meson_options.txt | 3 +++
> 4 files changed, 13 insertions(+)
>
> diff --git a/Kconfig.host b/Kconfig.host
> index 933425c74b..ec129aa4fc 100644
> --- a/Kconfig.host
> +++ b/Kconfig.host
> @@ -29,6 +29,9 @@ config IVSHMEM
> config TPM
> bool
>
> +config AUDIO
> + bool
> +
> config FDT
> bool
>
> diff --git a/configure b/configure
> index 4b61fd3bbf..ff391c79a1 100755
> --- a/configure
> +++ b/configure
> @@ -762,6 +762,10 @@ for opt do
> ;;
> --wasm64-32bit-address-limit)
> ;;
> + --enable-audio) meson_option_add -Daudio=true
> + ;;
> + --disable-audio) meson_option_add -Daudio=false
> + ;;
> # everything else has the same name in configure and meson
> --*) meson_option_parse "$opt" "$optarg"
> ;;
> diff --git a/meson.build b/meson.build
> index 8c6c0a9a32..69aa7cd189 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -68,6 +68,8 @@ foreach target : target_dirs
> endforeach
> have_user = have_linux_user or have_bsd_user
>
> +audio_enabled = get_option('audio')
You can use
audio_enabled = get_option('audio').disable_auto_if(not have_system)
and then replace all the "if have_system and audio_enabled" with just
"if audio_enabled".
That said, I'd rename the variable to "have_audio" for consistency with
other names in meson.build.
Paolo
> +
> ############
> # Programs #
> ############
> @@ -3244,6 +3246,7 @@ disassemblers = {
> have_ivshmem = config_host_data.get('CONFIG_EVENTFD')
> host_kconfig = \
> (get_option('fuzzing') ? ['CONFIG_FUZZ=y'] : []) + \
> + (audio_enabled ? ['CONFIG_AUDIO=y'] : []) + \
> (have_tpm ? ['CONFIG_TPM=y'] : []) + \
> (pixman.found() ? ['CONFIG_PIXMAN=y'] : []) + \
> (spice.found() ? ['CONFIG_SPICE=y'] : []) + \
> diff --git a/meson_options.txt b/meson_options.txt
> index 2836156257..172ed10ead 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -71,6 +71,9 @@ option('malloc_trim', type : 'feature', value : 'auto',
> option('malloc', type : 'combo', choices : ['system', 'tcmalloc', 'jemalloc'],
> value: 'system', description: 'choose memory allocator to use')
>
> +option('audio', type: 'boolean', value: true,
> + description: 'Audio support')
> +
> option('kvm', type: 'feature', value: 'auto',
> description: 'KVM acceleration support')
> option('mshv', type: 'feature', value: 'auto',
On 2/17/26 14:44, Paolo Bonzini wrote:
> On 2/17/26 06:27, Sergei Heifetz 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.
>>
>> Signed-off-by: Sergei Heifetz <heifetz@yandex-team.com>
>> ---
>> Kconfig.host | 3 +++
>> configure | 4 ++++
>> meson.build | 3 +++
>> meson_options.txt | 3 +++
>> 4 files changed, 13 insertions(+)
>>
>> diff --git a/Kconfig.host b/Kconfig.host
>> index 933425c74b..ec129aa4fc 100644
>> --- a/Kconfig.host
>> +++ b/Kconfig.host
>> @@ -29,6 +29,9 @@ config IVSHMEM
>> config TPM
>> bool
>> +config AUDIO
>> + bool
>> +
>> config FDT
>> bool
>> diff --git a/configure b/configure
>> index 4b61fd3bbf..ff391c79a1 100755
>> --- a/configure
>> +++ b/configure
>> @@ -762,6 +762,10 @@ for opt do
>> ;;
>> --wasm64-32bit-address-limit)
>> ;;
>> + --enable-audio) meson_option_add -Daudio=true
>> + ;;
>> + --disable-audio) meson_option_add -Daudio=false
>> + ;;
>> # everything else has the same name in configure and meson
>> --*) meson_option_parse "$opt" "$optarg"
>> ;;
>> diff --git a/meson.build b/meson.build
>> index 8c6c0a9a32..69aa7cd189 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -68,6 +68,8 @@ foreach target : target_dirs
>> endforeach
>> have_user = have_linux_user or have_bsd_user
>> +audio_enabled = get_option('audio')
>
> You can use
>
> audio_enabled = get_option('audio').disable_auto_if(not have_system)
>
> and then replace all the "if have_system and audio_enabled" with just
> "if audio_enabled".
>
> That said, I'd rename the variable to "have_audio" for consistency
> with other names in meson.build.
>
> Paolo
It looks nicer this way—thanks. I’ll then make the option a feature
rather than a boolean.
It would be `have_audio = get_option('audio').disable_auto_if(not
have_system).*allowed()*`, though.
>
>> +
>> ############
>> # Programs #
>> ############
>> @@ -3244,6 +3246,7 @@ disassemblers = {
>> have_ivshmem = config_host_data.get('CONFIG_EVENTFD')
>> host_kconfig = \
>> (get_option('fuzzing') ? ['CONFIG_FUZZ=y'] : []) + \
>> + (audio_enabled ? ['CONFIG_AUDIO=y'] : []) + \
>> (have_tpm ? ['CONFIG_TPM=y'] : []) + \
>> (pixman.found() ? ['CONFIG_PIXMAN=y'] : []) + \
>> (spice.found() ? ['CONFIG_SPICE=y'] : []) + \
>> diff --git a/meson_options.txt b/meson_options.txt
>> index 2836156257..172ed10ead 100644
>> --- a/meson_options.txt
>> +++ b/meson_options.txt
>> @@ -71,6 +71,9 @@ option('malloc_trim', type : 'feature', value :
>> 'auto',
>> option('malloc', type : 'combo', choices : ['system', 'tcmalloc',
>> 'jemalloc'],
>> value: 'system', description: 'choose memory allocator to use')
>> +option('audio', type: 'boolean', value: true,
>> + description: 'Audio support')
>> +
>> option('kvm', type: 'feature', value: 'auto',
>> description: 'KVM acceleration support')
>> option('mshv', type: 'feature', value: 'auto',
>
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" ? thanks -- PMM
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. I agree that this extra ifdef-ery is not great, and it's the only thing that makes me pause on this series. Paolo
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. thanks -- PMM
On Tue, Feb 17, 2026 at 11:06 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Tue, 17 Feb 2026 at 09:42, Paolo Bonzini <pbonzini@redhat.com> wrote: > > 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" ? Audio is special, it requires real time operation that is non-trivial to setup and consumes CPU time (and takes the BQL, introducing jitter in MMIO too). For pcspk for example the callback runs every 0.05 seconds (18 times a second) approximately. The code to setup this is in audio/audio.c and is independent of the backend. It is triggered by AUD_set_active_out (which causes audio_is_timer_needed to return true), meaning that "-audio none" runs a lot more code than just audio/noaudio.c. In addition, this real time operation is reflected into the pl041's interrupts, so you could have guest code that synchronizes itself on audio interrupts and a hobbled pl041 might not work at all. Unlikely for Linux guests, but bare metal code might do it. > Also, I think we should be consistent here, not put ifdefs in > some devices we think are "important" but skip it in others. pcspk is indeed "important", but (especially) it has no interrupts so there's no risk of breaking guests by removing audio output. Paolo
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 :|
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 <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 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.
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 <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 > 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 :|
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 <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 >> 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
On Tue, Feb 17, 2026 at 09:31:20AM +0000, 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" ? Don't we already have the ability to disable individual audio backends ? Each of them relies on a different 3rd party library that we have to check for, with none of them being mandatory. I feel like we shouldn't have a "--disable-audio" at all. For backends we always go for having ways to disable individual dependencies, and for frontends we provide Kconfig for fine tuning what's enabled for a given target. 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 :|
Hi! On 17/02/2026 06.27, Sergei Heifetz 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. > > Signed-off-by: Sergei Heifetz <heifetz@yandex-team.com> > --- ... > diff --git a/configure b/configure > index 4b61fd3bbf..ff391c79a1 100755 > --- a/configure > +++ b/configure > @@ -762,6 +762,10 @@ for opt do > ;; > --wasm64-32bit-address-limit) > ;; > + --enable-audio) meson_option_add -Daudio=true > + ;; > + --disable-audio) meson_option_add -Daudio=false > + ;; Changing "configure" should not be necessary. Please run "make scripts/meson-buildoptions.sh" instead and add the generated change to that file to your patch instead. Thanks, Thomas
On 2/17/26 13:40, Thomas Huth wrote: > Hi! > > On 17/02/2026 06.27, Sergei Heifetz 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. >> >> Signed-off-by: Sergei Heifetz <heifetz@yandex-team.com> >> --- > ... >> diff --git a/configure b/configure >> index 4b61fd3bbf..ff391c79a1 100755 >> --- a/configure >> +++ b/configure >> @@ -762,6 +762,10 @@ for opt do >> ;; >> --wasm64-32bit-address-limit) >> ;; >> + --enable-audio) meson_option_add -Daudio=true >> + ;; >> + --disable-audio) meson_option_add -Daudio=false >> + ;; > > Changing "configure" should not be necessary. Please run "make > scripts/meson-buildoptions.sh" instead and add the generated change to > that file to your patch instead. > > Thanks, > Thomas > Oh, that's how it works. Thanks, I'll fix it.
© 2016 - 2026 Red Hat, Inc.