Thanks everyone for bringing light to this discussion! Well, I support reverting the introduced changes as in https://github.com/apache/nuttx/pull/15767 and continue working on the https://github.com/apache/nuttx/pull/15705
In summary, I prefer to use Option 1: *Option 1:* > > spin_lock: spin lock > spin_lock_nopreempt: spin_lock + sched_lock > spin_lock_irqsave: spin lock + irqsave > spin_lock_irqsave_nopreempt: spin_lock + irq save + sched_lock I liked ligd's proposal too: Based on option1, we add a check if someone called sem_post()/syslog()... > then system ASSERT. Alert the people who should change their usage. > And also the performance will be considered. Best regards, Em qua., 5 de fev. de 2025 às 12:30, Sebastien Lorquet <sebast...@lorquet.fr> escreveu: > Hello, > > On 05/02/2025 15:43, chao an wrote: > > I just want to solve them. I know it's difficult for every developer. So > if > > you come across similar issues, you > > don't need to spend too much time trying to solve them on your own. > Yes, I understand very well, but fixing too fast can lead to bugs > elsewhere. NuttX is a complex code base, we need coordinated efforts. We > are a common project. > If you dont get feedback you need patience until you get feedback, and > you need to trigger more alarms. You cant just say "I didnt get the > feedback I required, this is fine, lets push this anyway". > > > On 05/02/2025 15:43, chao an wrote: > > Agree with you. This is precisely why I sent the spin_lock issue to the > > mailing list. It's to keep the semantics of > > the existing API consistent with the previous ones, so as to prevent > > individual developers and 3-party projects from > > spending more time debugging problems caused by NuttX upgrades. > > Thank you for forwarding to the list. > > However for this particular issue, it would be dishonest for me to give > advice because I just dont know. > > I hope the answers to your issues can be obtained from other contributors. > > Sebastien > >
