anchao commented on PR #17352:
URL: https://github.com/apache/nuttx/pull/17352#issuecomment-3556946813

   > @anchao
   > 
   > I understand the benefits of disabling signals and I like these, but as I 
mentioned, it's not POSIX-compliant. PSE51 also requires signal support, even 
if they make no practical sense in this case.
   > 
   > On the one hand, we want to remove `time_t` as 32-bit (#14460), which is 
POSIX-complaint, and on the other, we want to disable signals which is 
POSIX-incompatible. I see some inconsistency here. It would be good to 
establish some rules about when we can accept breaking POSIX and when we can't. 
I think we have a condition for this in `INVIOLABLES.md`, but it is not precise:
   > 
   > 
https://github.com/apache/nuttx/blob/fd70e5f947cb38f83503cc57b897e9cfb8368d9f/INVIOLABLES.md?plain=1#L29-L30
   
   Agree with you. You previously discussed how NuttX provides switches for 
other kernel features. These capabilities allow developers to achieve better 
memory footprint and performance while adhering to lightweight POSIX 
requirements, which I think is worthwhile:
   https://github.com/apache/nuttx/blob/master/sched/Kconfig#L6-L47
   
   > In this case voting on the mailing list would be a good idea.
   
   Yes, this requires a vote, and especially requires hearing @gregory-nutt 
voice.
   
   > 
   > BTW, do you have any comparisons between footprint and performers that 
could be presented as an argument for this change?
   
   I don't have detailed figures; here are some data from my memory:
   
   1. Data/bss: Each thread will reduce overhead by ~80 bytes (tcb_s)
   2. Text: Code size will be reduced by 4-7%, (mini shell configuration)
   3. Performance: thread create (3~5%), thread exit (3-5%), context switch 
event checking (3~5%)


-- 
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]

Reply via email to