Revert "libc/atomic: decoupling atomic and spinlock to avoid recursion"

[anchao]

Summary

Revert "pthread: We should not directly include arch/spinlock.h as it may cause compilation errors in C++."
Revert "sched/spinlock: remove nesting spinlock support"
Revert "libc/atomic: decoupling atomic and spinlock to avoid recursion"

Further work(without this feature could be closed):
#14200

Impact

N/A

Testing

ci-check

[nuttxpr]

[Experimental Bot, please feedback here]

This PR does not meet the NuttX requirements, despite claiming "N/A" for impact.

Here's why:

• Insufficient Summary: Simply stating "Revert" without explaining the original problem these commits aimed to solve, why they are problematic, and the implications of reverting is insufficient.
• Missing Impact Details: Reverting changes, especially those dealing with core components like pthread, scheduling, and atomic operations, will undoubtedly have an impact. Claiming "N/A" is misleading and unacceptable. The PR needs to clearly outline potential negative impacts like re-introducing bugs, breaking compatibility, or affecting performance.
• Vague Testing: "ci-check" isn't descriptive enough. The PR needs to specify the target architectures, boards, and configurations tested, along with relevant logs demonstrating the reverts don't negatively impact functionality.

In short, this PR needs significant work to meet NuttX standards. The author needs to:

1. Expand the Summary: Provide context for the reverts, explaining the original issue and the rationale for reverting.
2. Thoroughly Detail Impact: Analyze and document all potential impacts of these reverts, especially negative ones.
3. Improve Testing Description: Provide specific details about the testing environment and include comprehensive logs showcasing the before/after behavior.

Without these improvements, the PR is incomplete and risks introducing regressions into the NuttX codebase.

[GUIDINGLI]

@lupyuen
Could you help to see what happens to CI in this PR, haven't see any errors.

[GUIDINGLI]

I know what happens, will fix it in a quick time.

[lupyuen]

@GUIDINGLI Yep it's the same problem as apache/nuttx-apps#2716 (comment)

Configuration/Tool: qemu-armv8a/netnsh_smp_hv
  Normalize qemu-armv8a/netnsh_smp_hv
103d102
< CONFIG_SYSTEM_TELNETD_SESSION_STACKSIZE=8192
Saving the new configuration file
HEAD detached at pull/14218/merge

https://github.com/apache/nuttx/actions/runs/11320111668/job/31477184924?pr=14218

[GUIDINGLI]

Here is the fix:
#14229

[anchao]

@lupyuen @GUIDINGLI Please merge this PR if CI errors is not related to these commits

[lupyuen]

@GUIDINGLI @xiaoxiang781216 I'll let you decide when to merge this, since we are busy fixing the CI right now thanks :-)

[GUIDINGLI]

@GUIDINGLI @xiaoxiang781216 I'll let you decide when to merge this, since we are busy fixing the CI right now thanks :-)

OK, I am waiting for the CI result.

[GUIDINGLI]

@anchao
Please help to rebase this PR, thanks

[lupyuen]

@GUIDINGLI Yep I forked the NuttX Repo 30 mins ago, the CI looks OK so far :-)
https://github.com/lupyuen5/label-nuttx/actions/runs/11321795057

[GUIDINGLI]

Still CI error:
#14252

[GUIDINGLI]

@lupyuen
One suggestion, can we move the defconfig check to coding style check stage ?
Just configure & savedefconfig compare.
Then we can catch these questions in time before the compiling all the chips.

[lupyuen]

One suggestion, can we move the defconfig check to coding style check stage ?
Just configure & savedefconfig compare.

@GUIDINGLI Lemme think about this, the CI Build Flow is a little complicated, I'm still learning :-)

Also I wonder: Do we really need to build so many Arm Targets every time? If we build only the latest targets (e.g. SAMV7, Goldfish), then the problems will show up earlier. (And reduce our cost of GitHub Actions)

Or we should move SAMV7, Goldfish etc to the first job arm-01, keep the job small, so that it will fail earlier.

[GUIDINGLI]

One suggestion, can we move the defconfig check to coding style check stage ?
Just configure & savedefconfig compare.

@GUIDINGLI Lemme think about this, the CI Build Flow is a little complicated, I'm still learning :-)

Also I wonder: Do we really need to build so many Arm Targets every time? If we build only the latest targets (e.g. SAMV7, Goldfish), then the problems will show up earlier. (And reduce our cost of GitHub Actions)

Or we should move SAMV7, Goldfish etc to the first job arm-01, keep the job small, so that it will fail earlier.

Agreed with you.

I think we only need keep:
armv8-m armv8-a armv8-r
armv7-m armv7-a armv7-r
armv6-m
Each of them keep two/three boards is enough,
Each of them:
Flat mode, Kernel mode(if support), Qemu (if support)

How about others think about it ?

[lupyuen]

Let's discuss the Arm32 Targets here thanks!

• [FEATURE] Revising the Arm32 Targets for CI Build #14259