wangchdo commented on PR #17357: URL: https://github.com/apache/nuttx/pull/17357#issuecomment-3568642163
> > I can take care of this, and I'm happy to do so. > > By the way, since this is still under VOTING on the mailing list, I think this work is not very urgent. > > I think `DISABLE_SIGNAL` is unlikely to be affected by voting. Voting only affects whether to introduce PES-related definitions to limit kernel capabilities. Compared to `DISABLE_PTHREAD/TIMER`, `signal` is designed to achieve a smaller memory footprint > > > The detailed implementation is different, both approach could benefit in the different usage. It's better to introduce the disable level concept, so both pr could be merged. > > > > > > Why do we need two PRs for this? I already have a PR that disables signals. If the level-control approach works, it would be straightforward to integrate it into #17352. Opening a new PR would only consume additional reviewer time. I think we should focus on improving the existing PR instead. > > It's fine to use one pr to do the work, but someone need help to merge them. For example, for example, this pr contain more clean than #17352: https://github.com/apache/nuttx/pull/17357/files#diff-9e6b14f89a1f89e46914da0086d8e74e4d511ce0907333ca592dfda73368207fR132-R138 > > Bascially, we can arrange the pr into three part: > > 1. Skip the signal dispatch in each arch. Both pr do the same thing, but we need merge the change to ensure the skip completeness. > 2. One patch skip the signal dispatch in the common code > 3. Final patch skip all signal related function > > Who volunteers to complete this work? @wangchdo or @extinguish. Upon reconsideration, I prefer to only allow disabling all signal-related functionality, and re-implement the signal-dependent functions such as sleep()/usleep() using the newly added scheduler-based sleep APIs. This approach is clearer and safer. If we allow disabling only part of the signal subsystem, we would need to modify the implementations of the remaining signal functions. At the same time, we cannot guarantee that those functions will continue to behave exactly as before. Even worse, it becomes harder for users to understand the actual impact of partially disabling signal features. With PR https://github.com/apache/nuttx/pull/17200 introducing scheduler-based sleep support, and PR https://github.com/apache/nuttx/pull/17204 replacing all signal-based sleep implementations in drivers and the filesystem with scheduler-based versions, the overall dependency on signals has already been significantly reduced. We can re-implement the libc sleep()/usleep() functions using the new API added by PR https://github.com/apache/nuttx/pull/17368. This will even be more lightweight compared to the current signal-based wait mechanism. -- 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]
