xiaoxiang781216 commented on PR #17352: URL: https://github.com/apache/nuttx/pull/17352#issuecomment-3573885903
> > > @cederom: Thank you guys! I have sent the update on the mailing list with this PR and [apache/nuttx-apps#3217](https://github.com/apache/nuttx-apps/pull/3217) (applications update signal disable). > > > What is the Signal Disable impact on the Drivers? > > > > > > @xiaoxiang781216: With the partial signal disable solution, driver which notify the event to userspace through signal still work if it uses sigwaitinfo(not signal handler) to receive the event, for example, button driver notification example work as before: https://github.com/apache/nuttx/blob/master/include/nuttx/input/buttons.h#L77-L111 https://github.com/apache/nuttx-apps/blob/master/examples/buttons/buttons_main.c#L201-L256 but this example can't work with the full signal disable. On the other hand, timer driver example can't work with both approach: https://github.com/apache/nuttx-apps/blob/master/examples/timer/timer_main.c#L84-L97 since it receive the event through signal handler. > > @xiaoxiang781216 thank you! :-) > > So it looks like we have two general options and approaches, is this correct? > Yes. > 1. Partial Signals disable: > > * Safer and requires almost no modifications of existing code. > * Some things may be impacted (which one and how?). sigaction/signal and sigpending can't be used anymore, all othe sigxxx function work as before https://github.com/apache/nuttx/pull/17357/files#diff-b2638ab8551b8ccdc2caf1d064e4dd07ea1bcd1405a562591213d6ed10969594R175 https://github.com/apache/nuttx/pull/17357/files#diff-b2638ab8551b8ccdc2caf1d064e4dd07ea1bcd1405a562591213d6ed10969594R178 > * Moderate firmware size decrease (how much?). here is the number from: https://github.com/apache/nuttx/pull/17357 ``` When CONFIG_DISABLE_SIGNALS=n: Binary size = 1,295,424 bytes, Used RAM = 37,980 bytes When CONFIG_DISABLE_SIGNALS=y: Binary size = 1,262,624 bytes, Used RAM = 37,852 bytes This shows a reduction of 32,800 bytes in binary size and 128 bytes in RAM usage. ``` > * Option to decrease firmware size but with some impact to try-out-yourself (but why needed at all?). > 2. Full Signals disable: > > * Requires a lot of code modification, so better to assume special uses cases only with no other NuttX stuff operational. > * Existing code is impacted (almost all). > * Biggest possible firmware size decrease (18296->7492 2.44x Flash save, 1236->928 1.32x RAM save). > * Option to trim down firmware size with use-at-your-own-risk aka i-know-what-i-am-doing approach. > disable signal is just an option, just like many DISABLE_XXX option here: https://github.com/apache/nuttx/blob/master/sched/Kconfig#L18-L45 if you don't call these api, you can just disable it to save your code size. If you aren't sure whether you really use these api, enabling DISABLE_XXX in your defconfig, linker will report the result to you. > Maybe we can consider both options as possible or only one that offers biggest benefit at the lowest cost? > > * I just wonder how to organize this update so we don't flip all existing code upside down and now to create additional tons of work. Each update in each place is a potential problem later on. > * The partial signal disable option seems least invasive and not much places need an update right? Do we exactly know what is impacted (rtos, apps, drivers) and what would be the benefit (i.e. 50% of the firmware size decrease)? If its 50% size decrease then it may be worth the work, if 10% then maybe not worth it? > * The full signal disable is for extreme cases where people need to assume no other standard NuttX stuff will work but they want to keep the NuttX ecosystem while writing most of things on their own including applications and drivers? It's just a simple change(exclude the signal related functions from build), and the wrong config will report the link error, not runtime error. I can't understand why do we spend so spend so much time to consider the boring case. If your driver or apps use signal, don't enable CONFIG_DISABLE_SIGNALS, that's it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
