nuttxpr commented on PR #15439: URL: https://github.com/apache/nuttx/pull/15439#issuecomment-2574206522
[**\[Experimental Bot, please feedback here\]**](https://github.com/search?q=repo%3Aapache%2Fnuttx+13552&type=issues) No, this PR does not fully meet the NuttX requirements. While it provides a summary of the *what*, it lacks sufficient detail on the *why* and *how*. The impact section is insufficiently detailed, and the testing section is far too brief to be useful. Here's a breakdown of the missing information: * **Summary:** * **Why is this change *necessary*?** "Avoid potential deadlock situations" is vague. Which deadlock situations? How frequently do they occur? What are the consequences of these deadlocks? Provide concrete examples or link to relevant issues. * **How does the change work?** Simply stating "replace all spin_lock_irqsave to spin_lock_irqsave_wo_note" doesn't explain the mechanism. What is the difference between these two functions? Why is `spin_lock_irqsave_wo_note` preferable in this context? * **Impact:** "sched" is not an acceptable answer. Address *all* the impact points individually with "YES" or "NO" and provide details for any "YES" answers. For example: * **Impact on user:** Likely NO, but explain why the user shouldn't notice a difference. * **Impact on build:** Likely NO, but confirm. * **Impact on hardware:** Specify the affected architectures. Even if it's all architectures, state that explicitly. * **Impact on documentation:** Does this change require documentation updates? * **Impact on security:** Does this change have any security implications (positive or negative)? * **Impact on compatibility:** Are there any backward compatibility concerns? * **Testing:** "ci" is unacceptable. Provide specific details about the testing environment: * **Build Host(s):** List the operating system, CPU architecture, and compiler version used for the build. * **Target(s):** List the target architecture(s) and board configurations tested. * **Testing Logs:** Include *actual* logs demonstrating the issue before the change and the improved behavior after the change. Simply stating that it "works as intended" is not sufficient proof. Show evidence of the deadlock being avoided. In short, the PR needs significantly more detail to be acceptable. It needs to clearly explain the problem being solved, the chosen solution, the rationale behind the solution, and provide concrete evidence that the solution works as intended. -- 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]
