sched/signals: add support to partially or fully disable signals

[wangchdo]

Summary

Signals in NuttX serve two primary purposes:

1. Synchronization and wake-up
   Signals can be used to block threads on specific signal sets and later wake them up by delivering the corresponding signals to those threads.

2. Asynchronous notification
   Signals can also be used to register callback handlers for specific signals, allowing threads to asynchronously invoke those handlers when the signals are delivered.

The PR #17357 Introduced the ability to disable only the synchronization and wake-up functionality of signals, while retaining part of the signal infrastructure. This allows moderate memory savings and performance improvements.

The PR #17352 Introduced the ability to completely disable all signal functionality, providing more aggressive memory reduction and performance optimization.

This PR consolidates the above two efforts and introduces a unified mechanism that supports both:

1. Partial signal disablement: disabling only asynchronous notification while retaining synchronization and wake-up functionality.

2. Full signal disablement: disabling both synchronization / wake-up and asynchronous notification functionality.

This consolidation enables finer-grained control over signal usage, allowing system integrators to better balance functionality, memory footprint, and performance for different use cases.

Impact

Provide configuration to fully or partially disable signals, should have no impact to exist nuttx functions if
the configuration is not enabled

this PR depends on apache/nuttx-apps#3265 to fix build dependency issues when signals are partially or fully disabled.

Testing

Below tests depend on apache/nuttx-apps#3265

ostest passed on rv-virt:smp64 when CONFIG_ENABLE_PARTIAL_SIGNALS=y

nsh> uname -a
NuttX 0.0.0 3503bbec44-dirty Dec 23 2025 11:32:43 risc-v rv-virt
nsh> ostest

(...)

smp_call_test: Call cpu 1, wait
smp_call_test: Call cpu 2, nowait
smp_call_test: Call cpu 2, wait
smp_call_test: Call cpu 3, nowait
smp_call_test: Call cpu 3, wait
smp_call_test: Call cpu 4, nowait
smp_call_test: Call cpu 4, wait
smp_call_test: Call cpu 5, nowait
smp_call_test: Call cpu 5, wait
smp_call_test: Call cpu 6, nowait
smp_call_test: Call cpu 6, wait
smp_call_test: Call cpu 7, nowait
smp_call_test: Call cpu 7, wait
smp_call_test: Call multi cpu, nowait
smp_call_test: Call in interrupt, wait
smp_call_test: Call multi cpu, wait
smp_call_test: Test success

Final memory usage:
VARIABLE  BEFORE   AFTER
======== ======== ========
arena     1fc23e0  1fc23e0
ordblks         1        7
mxordblk  1fb72f0  1fa4140
uordblks     b0f0    14df8
fordblks  1fb72f0  1fad5e8
user_main: Exiting
ostest_main: Exiting with status 0

[acassis]

@Fix-Point please help to review

[linguini1]

Could you try testing on some real hardware?

Also, did we decide that we're allowing signals to be disabled? I remember there was a big discussion about it.

[xiaoxiang781216]

Could you try testing on some real hardware?

Also, did we decide that we're allowing signals to be disabled? I remember there was a big discussion about it.

@linguini1 This patch just make signal function optional, I don't see any reason to not merge this pr. As I said before if you don't allow this patch merge, which mean you must remove ALL option from Kconfig which are required POSIX(e.g. thread, environment variable, file and even nsh) since these feature are required by POSIX spec.

So, I don't know why do we need ask the vote in dev thread.

[xiaoxiang781216]

@wangchdo please fix the comment in apache/nuttx-apps#3265, so we can merge both pr together.

[linguini1]

@linguini1 This patch just make signal function optional, I don't see any reason to not merge this pr. As I said before if you don't allow this patch merge, which mean you must remove ALL option from Kconfig which are required POSIX(e.g. thread, environment variable, file and even nsh) since these feature are required by POSIX spec.

Don't worry, I am not opposed to this PR and I will not block it from merging. I was just curious what the resolution of that discussion was in case someone was able to fill me in. I personally support the optional disabling of POSIX interfaces if they are unused and can help save system resources.