Skip to content

Conversation

@wangchdo
Copy link
Contributor

@wangchdo wangchdo commented Dec 23, 2025

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

wangchdo and others added 11 commits December 23, 2025 10:16
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 install callback handlers for specific signals, allowing threads to
   asynchronously invoke those handlers when the signals are delivered.

This change introduces the ability to partially disable signal functionality: to disable only signal functions for
Asynchronous notification, keeping functions for Synchronization and wake-up.
This enables finer-grained control over signal usage while preserving existing behavior for supported use cases.

Co-authored-by: Guo Shichao guoshichao@xiaomi.com
Signed-off-by: Chengdong Wang wangchengdong@lixiang.com
    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 install callback handlers for specific signals, allowing threads to
       asynchronously invoke those handlers when the signals are delivered.

    This change introduces the ability to  disable all signal functionality to reduce footprint for NuttX.

Signed-off-by: Chengdong Wang wangchengdong@lixiang.com
   Add support to disable signals actions related struct

Co-authored-by: guoshichao <guoshichao@xiaomi.com>
Signed-off-by: Chengdong Wang <wangchengdong@lixiang.com>
   Add support to disable signals actions related struct

Co-authored-by: guoshichao <guoshichao@xiaomi.com>
Signed-off-by: Chengdong Wang <wangchengdong@lixiang.com>
   Add support to disable signals actions related struct

Co-authored-by: guoshichao <guoshichao@xiaomi.com>
Signed-off-by: Chengdong Wang <wangchengdong@lixiang.com>
   Add support to disable signals actions related struct

Co-authored-by: guoshichao <guoshichao@xiaomi.com>
Signed-off-by: Chengdong Wang <wangchengdong@lixiang.com>
   Add support to disable signals actions related struct

Co-authored-by: guoshichao <guoshichao@xiaomi.com>
Signed-off-by: Chengdong Wang <wangchengdong@lixiang.com>
   Add support to disable signals actions related struct

Co-authored-by: guoshichao <guoshichao@xiaomi.com>
Signed-off-by: Chengdong Wang <wangchengdong@lixiang.com>
   Add support to disable signals actions related struct

Co-authored-by: guoshichao <guoshichao@xiaomi.com>
Signed-off-by: Chengdong Wang <wangchengdong@lixiang.com>
   Add support to disable signals actions related struct

Co-authored-by: guoshichao <guoshichao@xiaomi.com>
Signed-off-by: Chengdong Wang <wangchengdong@lixiang.com>
   Add support to disable signals actions related struct

Co-authored-by: guoshichao <guoshichao@xiaomi.com>
Signed-off-by: Chengdong Wang <wangchengdong@lixiang.com>
@github-actions github-actions bot added Arch: arm Issues related to ARM (32-bit) architecture Arch: arm64 Issues related to ARM64 (64-bit) architecture Arch: risc-v Issues related to the RISC-V (32-bit or 64-bit) architecture labels Dec 23, 2025
@github-actions github-actions bot added Arch: tricore Issues related to the TriCore architecture from Infineon Arch: x86 Issues related to the x86 architecture Arch: x86_64 Issues related to the x86_64 architecture Arch: xtensa Issues related to the Xtensa architecture Arch: z16 Issues related to the Z16 architecture Arch: z80 Issues related to the Z80 architecture Area: Drivers Drivers issues Area: File System File System issues Area: OS Components OS Components issues Size: L The size of the change in this PR is large labels Dec 23, 2025
@acassis
Copy link
Contributor

acassis commented Dec 25, 2025

@Fix-Point please help to review

@Fix-Point
Copy link
Contributor

After disabling the nxsig_unmask_pendingsignal API, there seems to be a compilation error.

signal/sig_ppoll.c:102:7: warning: implicit declaration of function 'nxsig_unmask_pendingsignal'; did you mean 'nxsig_remove_pendingsignal'? [-Wimplicit-function-declaration]
  102 |   if (nxsig_unmask_pendingsignal())
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~
      |       nxsig_remove_pendingsignal
CC:  net/lib_addrconfig.c signal/sig_pselect.c: In function 'pselect':
signal/sig_pselect.c:99:7: warning: implicit declaration of function 'nxsig_unmask_pendingsignal'; did you mean 'nxsig_remove_pendingsignal'? [-Wimplicit-function-declaration]
   99 |   if (nxsig_unmask_pendingsignal())
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~
      |       nxsig_remove_pendingsignal
CC:  net/lib_base64.c signal/sig_suspend.c: In function 'sigsuspend':
signal/sig_suspend.c:111:7: warning: implicit declaration of function 'nxsig_unmask_pendingsignal'; did you mean 'nxsig_remove_pendingsignal'? [-Wimplicit-function-declaration]
  111 |   if (nxsig_unmask_pendingsignal())
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~
      |       nxsig_remove_pendingsignal

Some files also call nxsig_unmask_pendingsignal. Please be aware of whether this may cause a compilation error.

  • arch/arm/src/armv6-m/arm_svcall.c: line 207
  • arch/arm/src/armv7-a/arm_syscall.c: line 263
  • arch/arm/src/armv7-m/arm_svcall.c: line 215
  • arch/arm/src/armv7-r/arm_syscall.c: line 260
  • arch/arm/src/armv8-m/arm_svcall.c: line 215
  • arch/arm/src/armv8-r/arm_syscall.c: line 260
  • arch/arm64/src/common/arm64_syscall.c: line 143
  • arch/mips/src/mips32/mips_swint0.c: line 224
  • arch/misoc/src/lm32/lm32_swint.c: line 222
  • arch/misoc/src/minerva/minerva_swint.c: line 193
  • arch/risc-v/src/common/riscv_swint.c: line 134
  • arch/xtensa/src/common/xtensa_swint.c: line 159

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Arch: arm Issues related to ARM (32-bit) architecture Arch: arm64 Issues related to ARM64 (64-bit) architecture Arch: risc-v Issues related to the RISC-V (32-bit or 64-bit) architecture Arch: tricore Issues related to the TriCore architecture from Infineon Arch: x86 Issues related to the x86 architecture Arch: x86_64 Issues related to the x86_64 architecture Arch: xtensa Issues related to the Xtensa architecture Arch: z16 Issues related to the Z16 architecture Arch: z80 Issues related to the Z80 architecture Area: Drivers Drivers issues Area: File System File System issues Area: OS Components OS Components issues Size: L The size of the change in this PR is large

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants