The Life of a Single Request
A request’s journey through creation, translation, queueing, transfer, completion, and release.
Creation gives the request an owner
A caller creates or causes an operation to be represented with an interface, parameters, buffers, and an expected completion. The first driver layer validates the representation and decides which lower-layer contract applies.
Translation changes form
A request can become a class operation, a bus transfer, a controller command, or a set of descriptors. The meaning should remain connected across forms even though each layer owns different structures.
Queueing and transfer separate time
The request may wait while a device, resource, or power state becomes available. Once submitted, the driver tracks completion and retains ownership of buffers and related state until the contract permits release.
Completion closes the loop
A result, status, and byte count or equivalent outcome return to the caller. Cleanup, cancellation, and reference release complete the lifecycle so that no layer treats a finished request as still active.
Reference facts
- Lifecycle
- Create, validate, translate, queue, submit, complete, and release.
- Ownership
- Buffers and request state remain owned until the contract permits hand-off.
Questions and answers
Can one request become several lower-level operations?
Yes. A higher-level operation can be translated into multiple transfers or commands, each with its own completion relationship.
What does completion communicate?
It communicates status and result information while signaling that the responsible layer can release or transfer request resources.