driver-api/surface_aggregator/internal.rst

63 Lower-level packet transport is implemented in the *packet transport layer
65 infrastructure of the kernel. As the name indicates, this layer deals with
70 Above this sits the *request transport layer (RTL)*. This layer is centered
76 The *controller* layer is building on top of this and essentially decides
81 ``RQID``). This layer basically provides a fundamental interface to the SAM
84 While the controller layer already provides an interface for other kernel
97 Packet Transport Layer
100 The packet transport layer is represented via |ssh_ptl| and is structured
107 managed by the packet transport layer, which is essentially the lowest layer
114 transport layer, as well as a reference to the buffer containing the data to
126 submitted to the packet transport layer, the ``complete()`` callback is
156 packet transport layer. It is a priority queue, with priority of the
160 All packets to be transmitted by the transport layer must be submitted to
162 sent by the transport layer itself. Internally, data packets can be
169 packet transport layer. It stores references to packets that have already
216 Any payload data is forwarded via a callback to the next upper layer, i.e.
217 the request transport layer.
243 transport layer is always guaranteed to make progress, if only through
249 There are two main locks in the packet transport layer: One guarding access
261 Other parts of the packet transport layer are guarded independently. State
266 The reference of the packet to the packet transport layer (``ptl``) is
267 somewhat special. It is either set when the upper layer request is submitted
281 (|ssh_ptl_rx_rcvbuf|), and layer shutdown (|ssh_ptl_shutdown|) may always be
288 Request Transport Layer
291 The request transport layer is represented via |ssh_rtl| and builds on top
292 of the packet transport layer. It deals with requests, i.e. SSH packets sent
293 by the host containing a |ssh_command| as frame payload. This layer
295 via a |ssh_command| payload. While responses are handled in this layer,
296 events are relayed to the next upper layer, i.e. the controller layer, via
297 the corresponding callback. The request transport layer is structured around
319 flags provided to |ssh_request_init|, so that the request transport layer
325 layer via |ssh_rtl_submit|. For a request without a response, successful
327 transmitted by the packet transport layer (i.e. from within the packet
330 via its request ID (which happens on the packet layer's data-received
360 request transport layer. In contrast to the packet queue of the packet
361 transport layer, it is not a priority queue and the simple first come first
364 All requests to be transmitted by the request transport layer must be
375 request transport layer. This collection stores references to all pending
377 pending set of the packet transport layer does for packets).
385 transport layer. This check ensures that only a limited number of
406 The data received callback notifies the request transport layer of data
407 being received by the underlying packet transport layer via a data-type
412 event callback registered in the request transport layer. If the request ID
426 transport layer, handled via a dedicated reaper task. This task is
434 acknowledgment timeouts, guarantees that the request layer will always make
440 Similar to the packet transport layer, there are two main locks in the
441 request transport layer: One guarding access to the request queue and one
445 Other parts of the request transport layer are guarded independently. State
456 (|ssh_rtl_submit|), request cancellation (|ssh_rtl_cancel|), and layer
463 Controller Layer
466 The controller layer extends on the request transport layer to provide an
470 layer takes on more of a management role. Specifically, it handles device
540 installed in the request layer (running on the receiver thread of the packet
541 transport layer), it will be put on its respective event queue
557 provided by the lower-level request transport layer. In addition to this,