6 Commits

Author SHA1 Message Date
Alin Jerpelea
068220d3a7 testing: migrate to SPDX identifier
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.

Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
2024-12-30 18:02:50 +08:00
hujun5
39908cc40c isrthread: add configuring the stack of an isrthread as static
reason:
we configure the isr thread stack as static to allow for more flexible placement of the stack.

Signed-off-by: hujun5 <hujun5@xiaomi.com>
2024-11-08 01:49:20 +08:00
ligd
48db89158a ostest: update wqueue test for new API
Signed-off-by: ligd <liguiding1@xiaomi.com>
2024-10-29 01:22:29 +08:00
Zhe Weng
87838bb62c ostest/wqueue: Check return value for pthread ops.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
2023-08-22 13:55:03 +08:00
hujun5
f0f98c3d73 ostest: fix smp ostest fail
In SMP we need improve thread waiting strategy

Signed-off-by: hujun5 <hujun5@xiaomi.com>
2023-04-24 09:55:54 +02:00
Zhe Weng
412505d286 ostest: Introduce basic work queue test
The test consists of two parts:
- A tester that tries to trigger wrong states of work queue
- A verifier that checks whether the wqueue is still working properly

The tester is trying to queue and cancel work several times with
priority lower/same/higher than the work queue.

Most wrong cases are likely to happen with high priority like:
- If `cancel` never decreases semcount, the count may keep growing
  and finally overflow
- If `cancel` is decreasing semcount too much, the `work_thread` may
  be waken up less times than expected

The lower/same priority testers are just added for covering other
unexpected situations.

The verifier is trying to queue some works and check they are called as
expected:
- Frist queue a 'sleep' worker, to let a work queue thread be in busy
  status and not waiting on sem, while other work queue thread(s) (if
  any) still waiting for sem. If sem is in wrong state, it may cause
  wrong behavior in either thread waiting/not waiting on the sem.
- Then queue a few count works, if the work queue(s) are still working
  properly, these works should finally be all called once.

Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
2023-03-22 12:56:01 +02:00