CV-Bowen opened a new pull request, #21385:
URL: https://github.com/apache/nuttx/pull/21385

   ## Summary
   
   Add three work queue APIs that a driver owning its own queues needs:
   
   - `work_queue_in_queue()`: whether the caller runs on one of the
     queue's worker threads.
   - `work_queue_dispatch()`: run the expired work of a queue from one of
     its worker threads. `work_thread()`'s loop is moved into
     `work_dispatch()` for that; the exit checks added by "harden custom
     queue lifecycle" are kept.
   - `work_queue_setpriority()`/`work_queue_setpriority_wq()`: the setter
     matching `work_queue_priority()`.
   
   The rpmsg rx work queues use all three: rx is handled on per device
   queues, an rpmsg call that waits on a reply from a worker thread drains
   its own queue with `work_queue_dispatch()` meanwhile, and a queue runs
   at the priority of the endpoints it serves. That rpmsg change follows in
   a separate PR.
   
   ## Impact
   
   API additions only. Existing queues behave as before: the worker loop
   runs the same steps, only from a function.
   
   ## Testing
   
   Host: Ubuntu 22.04.5 LTS x86_64, QEMU version 10.2.1, sim: cc (Ubuntu 
13.1.0-8ubuntu1~22.04) 13.1.0, qemu-armv8a: aarch64-none-elf-gcc (Arm GNU 
Toolchain 12.2.Rel1 (Build arm-12.24)) 12.2.1 20221205
   
   sim:smp (4 CPUs):
   
   - `ostest wqueue`: all cases pass (HPWORK, custom queue with 1 and 2
     threads, priority, periodic requeue, pending replacement, sync and
     parallel cancel, teardown, self free).
   - A test-only app (not in this PR) on a custom queue with one thread:
     `work_queue_in_queue()` is false from main and true from a work item;
     a work item queues a second item and calls `work_queue_dispatch()`,
     and the second item has run when the call returns (with one thread it
     can only run there); `work_queue_setpriority_wq(wq, 120)` makes
     `work_queue_priority_wq()` return 120 and an out of range priority
     returns -EINVAL. Output: `WQTEST PASS`.
   
   sim:ostest: the full ostest (5 loops) runs the wqueue test in each loop
   with every `call = 100, expect = 100`.
   
   <details><summary>ostest wqueue on sim:smp</summary>
   
   ```
   WQTEST PASS
   wqueue_test: backend = flat
   wqueue_test: HPWORK
   wqueue_test: HPWORK done
   wqueue_test: custom queue, threads = 1
   wqueue_test: priority = 100, expect = 100
   wqueue_test: API validation
   wqueue_test: API validation done
   wqueue_test: periodic requeue
   wqueue_test: periodic calls = 3, expect = 3
   wqueue_test: pending replacement
   wqueue_test: replacement total = 2, expect = 2
   wqueue_test: sync cancel finished = 1, expect = 1
   wqueue_test: custom queue, threads = 1 done
   wqueue_test: custom queue, threads = 2
   wqueue_test: priority = 100, expect = 100
   wqueue_test: sync cancel finished = 1, expect = 1
   wqueue_test: parallel sync cancel
   wqueue_test: parallel callbacks = 2, expect = 2
   wqueue_test: custom queue, threads = 2 done
   wqueue_test: multiple custom queues
   wqueue_test: multiple queues loop 1/4 done
   wqueue_test: multiple queues loop 2/4 done
   wqueue_test: multiple queues loop 3/4 done
   wqueue_test: multiple queues loop 4/4 done
   wqueue_test: multiple custom queues done
   wqueue_test: self free
   wqueue_test: self free result = -35, expect = -35
   wqueue_test: teardown
   wqueue_test: pending callback = 0, expect = 0
   wqueue_test: running callback = 1, expect = 1
   wqueue_test: teardown requeue rejected
   wqueue_test: teardown done
   ```
   </details>
   
   rpmsg baseline:
   
   No regression in rpmsg: sim:rpserver/rpproxy and 
qemu-armv8a:rpserver/rpproxy boot and pass the fixed rpmsg cases (dump, ping, 
rpmsgfs; 15/15). qemu-armv8a was built with LIBC_ENVPATH and BINFMT_CHECKEXEC 
disabled, which current master needs for nxinit to start nsh there; unrelated 
to this change.
   


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