Lines Matching +full:c +full:- +full:version +full:- +full:name
1 .. SPDX-License-Identifier: BSD-3-Clause
9 the ``genetlink-legacy`` protocol level.
15 -------
19 version subsection
22 Generic Netlink family version, default is 1.
24 ``version`` has historically been used to introduce family changes
26 are generally not allowed ``version`` is very rarely used.
29 --------------------
31 New Netlink families should use ``multi-attr`` to define arrays.
35 For reference the ``multi-attr`` array may look like this::
37 [ARRAY-ATTR]
41 [SOME-OTHER-ATTR]
42 [ARRAY-ATTR]
47 where ``ARRAY-ATTR`` is the array entry type.
49 indexed-array
52 ``indexed-array`` wraps the entire array in an extra attribute (hence
56 A ``sub-type`` is needed to describe what type in the ``ENTRY``. A ``nest``
57 ``sub-type`` means there are nest arrays in the ``ENTRY``, with the structure
60 [SOME-OTHER-ATTR]
61 [ARRAY-ATTR]
69 Other ``sub-type`` like ``u32`` means there is only one member as described
70 in ``sub-type`` in the ``ENTRY``. The structure looks like::
72 [SOME-OTHER-ATTR]
73 [ARRAY-ATTR]
77 type-value
80 ``type-value`` is a construct which uses attribute types to carry
82 entry-by-entry).
84 ``type-value`` can have multiple levels of nesting, for example
87 [POLICY-IDX]
88 [ATTR-IDX]
89 [POLICY-INFO-ATTR1]
90 [POLICY-INFO-ATTR2]
94 type. Inside the attr-index nest are the policy attributes. Modern
102 -----------------------
113 .. code-block:: yaml
115 -
116 name: a
119 -
120 name: b
122 -
123 name: c
126 -
127 name: d
131 the requests and responses of ``b`` - 2 (since there is no explicit
132 ``value`` it's previous operation ``+ 1``). Notification ``c`` will
147 only allocates a ``reply`` (i.e. a "from-kernel" ID). Let's look
150 .. code-block:: yaml
152 -
153 name: a
161 -
162 name: b
164 -
165 name: c
168 -
169 name: d
174 a "from-kernel" ID which is 2. ``c`` allocates "from-kernel" ID of 7.
177 with a request section and the value of 2) and 8 for response (``c`` is
178 the previous operation in the "from-kernel" direction).
184 ----------
186 Legacy families can define C structures both to be used as the contents of
193 - ``name`` - The attribute name of the struct member
194 - ``type`` - One of the scalar types ``u8``, ``u16``, ``u32``, ``u64``, ``s8``,
196 - ``byte-order`` - ``big-endian`` or ``little-endian``
197 - ``doc``, ``enum``, ``enum-as-flags``, ``display-hint`` - Same as for
200 Note that structures defined in YAML are implicitly packed according to C
203 .. code-block:: c
208 u8 c;
211 Any padding must be explicitly added and C-like languages should infer the
216 .. code-block:: yaml
219 -
220 name: message-header
223 -
224 name: a
226 -
227 name: b
229 -
230 name: c
236 Fixed message headers can be added to operations using ``fixed-header``.
237 The default ``fixed-header`` can be set in ``operations`` and it can be set
240 .. code-block:: yaml
243 fixed-header: message-header
245 -
246 name: get
247 fixed-header: custom-header
248 attribute-set: message-attrs
253 A ``binary`` attribute can be interpreted as a C structure using a
254 ``struct`` property with the name of the structure definition. The
255 ``struct`` property implies ``sub-type: struct`` so it is not necessary to
256 specify a sub-type.
258 .. code-block:: yaml
260 attribute-sets:
261 -
262 name: stats-attrs
264 -
265 name: stats
267 struct: vport-stats
269 C Arrays
270 --------
272 Legacy families also use ``binary`` attributes to encapsulate C arrays. The
273 ``sub-type`` is used to identify the type of scalar to extract.
275 .. code-block:: yaml
278 -
279 name: ports
281 sub-type: u32
283 Multi-message DO
284 ----------------
290 perhaps with values of ``combine`` and ``multi-object`` depending