Client and service model
QMI uses a client/service model. A client can communicate with multiple services, and a service can serve multiple clients. Communication has two forms:- Request and response – A client sends an operation request and matches the response to that request.
- Indication – A service sends an unsolicited event after a client registers to receive a class of events.
QMI message format
A QMI message has a small header followed by a series of typed fields. Each field is identified by a type tag, so the receiver knows what data to expect. This format lets the same message structure be used for requests, responses, and indications without requiring separate hand-written encoders for each one.Marshaling and transport separation
The encode/decode library converts between the C structures your code uses and the QMI wire format. The interface library manages QMI handles, service connections, callbacks, and message transport. Keeping these responsibilities separate lets a driver describe its data once and use the same codec for requests, responses, and indications.Concurrency and latency
The codec does not access global shared state and can be used without codec-level locking. The interface library protects shared resources with mutexes. QMI messages should remain short enough for the latency requirements of the client; large or slow operations should be designed with explicit asynchronous completion rather than holding a synchronous request open indefinitely.Next steps
- Client API — Create clients, connect to services, and send requests
- Service API — Register services and handle client requests
- Examples — See how request/response and indication exchanges work