Deferring Work to a Workqueue
When something happens in a place where you may not sleep, the standard answer is to queue a job for later in a kernel thread that may. A work item is a small structure embedded in your own state plus a function to run; queueing it schedules the run, and queueing it twice while it is pending is harmlessly ignored. In Rust a macro declares which field of your structure is the work item so the kernel can find your data from the work pointer, and the queued value keeps a reference-counted handle alive until the job has run. Without it, an interrupt handler that needs to allocate or lock has nowhere to do it.
Questions this Concept answers
- Why does the Rust work-item macro need to be told which field of your structure holds the work item?
Workqueues as a Bottom-Half Mechanism in Linux Device Drivers
Workqueues are a Linux kernel "bottom-half" deferred-work mechanism that let an interrupt handler offload non-urgent work to a queue of tasks executed later in a process (kernel-thread) context rathe…