1 .. SPDX-License-Identifier: BSD-3-Clause 1 .. SPDX-License-Identifier: BSD-3-Clause
2 2
3 ========================================= 3 =========================================
4 Netlink protocol specifications (in YAML) 4 Netlink protocol specifications (in YAML)
5 ========================================= 5 =========================================
6 6
7 Netlink protocol specifications are complete, 7 Netlink protocol specifications are complete, machine readable descriptions of
8 Netlink protocols written in YAML. The goal of 8 Netlink protocols written in YAML. The goal of the specifications is to allow
9 separating Netlink parsing from user space log 9 separating Netlink parsing from user space logic and minimize the amount of
10 hand written Netlink code for each new family, 10 hand written Netlink code for each new family, command, attribute.
11 Netlink specs should be complete and not depen 11 Netlink specs should be complete and not depend on any other spec
12 or C header file, making it easy to use in lan 12 or C header file, making it easy to use in languages which can't include
13 kernel headers directly. 13 kernel headers directly.
14 14
15 Internally kernel uses the YAML specs to gener 15 Internally kernel uses the YAML specs to generate:
16 16
17 - the C uAPI header 17 - the C uAPI header
18 - documentation of the protocol as a ReST fil !! 18 - documentation of the protocol as a ReST file
19 - policy tables for input attribute validatio 19 - policy tables for input attribute validation
20 - operation tables 20 - operation tables
21 21
22 YAML specifications can be found under ``Docum 22 YAML specifications can be found under ``Documentation/netlink/specs/``
23 23
24 This document describes details of the schema. 24 This document describes details of the schema.
25 See :doc:`intro-specs` for a practical startin 25 See :doc:`intro-specs` for a practical starting guide.
26 26
27 All specs must be licensed under 27 All specs must be licensed under
28 ``((GPL-2.0 WITH Linux-syscall-note) OR BSD-3- 28 ``((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)``
29 to allow for easy adoption in user space code. 29 to allow for easy adoption in user space code.
30 30
31 Compatibility levels 31 Compatibility levels
32 ==================== 32 ====================
33 33
34 There are four schema levels for Netlink specs 34 There are four schema levels for Netlink specs, from the simplest used
35 by new families to the most complex covering a 35 by new families to the most complex covering all the quirks of the old ones.
36 Each next level inherits the attributes of the 36 Each next level inherits the attributes of the previous level, meaning that
37 user capable of parsing more complex ``genetli 37 user capable of parsing more complex ``genetlink`` schemas is also compatible
38 with simpler ones. The levels are: 38 with simpler ones. The levels are:
39 39
40 - ``genetlink`` - most streamlined, should be 40 - ``genetlink`` - most streamlined, should be used by all new families
41 - ``genetlink-c`` - superset of ``genetlink`` 41 - ``genetlink-c`` - superset of ``genetlink`` with extra attributes allowing
42 customization of define and enum type and v 42 customization of define and enum type and value names; this schema should
43 be equivalent to ``genetlink`` for all impl 43 be equivalent to ``genetlink`` for all implementations which don't interact
44 directly with C uAPI headers 44 directly with C uAPI headers
45 - ``genetlink-legacy`` - Generic Netlink catc 45 - ``genetlink-legacy`` - Generic Netlink catch all schema supporting quirks of
46 all old genetlink families, strange attribu 46 all old genetlink families, strange attribute formats, binary structures etc.
47 - ``netlink-raw`` - catch all schema supporti 47 - ``netlink-raw`` - catch all schema supporting pre-Generic Netlink protocols
48 such as ``NETLINK_ROUTE`` 48 such as ``NETLINK_ROUTE``
49 49
50 The definition of the schemas (in ``jsonschema 50 The definition of the schemas (in ``jsonschema``) can be found
51 under ``Documentation/netlink/``. 51 under ``Documentation/netlink/``.
52 52
53 Schema structure 53 Schema structure
54 ================ 54 ================
55 55
56 YAML schema has the following conceptual secti 56 YAML schema has the following conceptual sections:
57 57
58 - globals 58 - globals
59 - definitions 59 - definitions
60 - attributes 60 - attributes
61 - operations 61 - operations
62 - multicast groups 62 - multicast groups
63 63
64 Most properties in the schema accept (or in fa 64 Most properties in the schema accept (or in fact require) a ``doc``
65 sub-property documenting the defined object. 65 sub-property documenting the defined object.
66 66
67 The following sections describe the properties 67 The following sections describe the properties of the most modern ``genetlink``
68 schema. See the documentation of :doc:`genetli 68 schema. See the documentation of :doc:`genetlink-c <c-code-gen>`
69 for information on how C names are derived fro 69 for information on how C names are derived from name properties.
70 70
71 See also :ref:`Documentation/core-api/netlink. 71 See also :ref:`Documentation/core-api/netlink.rst <kernel_netlink>` for
72 information on the Netlink specification prope 72 information on the Netlink specification properties that are only relevant to
73 the kernel space and not part of the user spac 73 the kernel space and not part of the user space API.
74 74
75 genetlink 75 genetlink
76 ========= 76 =========
77 77
78 Globals 78 Globals
79 ------- 79 -------
80 80
81 Attributes listed directly at the root level o 81 Attributes listed directly at the root level of the spec file.
82 82
83 name 83 name
84 ~~~~ 84 ~~~~
85 85
86 Name of the family. Name identifies the family 86 Name of the family. Name identifies the family in a unique way, since
87 the Family IDs are allocated dynamically. 87 the Family IDs are allocated dynamically.
88 88
89 protocol 89 protocol
90 ~~~~~~~~ 90 ~~~~~~~~
91 91
92 The schema level, default is ``genetlink``, wh 92 The schema level, default is ``genetlink``, which is the only value
93 allowed for new ``genetlink`` families. 93 allowed for new ``genetlink`` families.
94 94
95 definitions 95 definitions
96 ----------- 96 -----------
97 97
98 Array of type and constant definitions. 98 Array of type and constant definitions.
99 99
100 name 100 name
101 ~~~~ 101 ~~~~
102 102
103 Name of the type / constant. 103 Name of the type / constant.
104 104
105 type 105 type
106 ~~~~ 106 ~~~~
107 107
108 One of the following types: 108 One of the following types:
109 109
110 - const - a single, standalone constant 110 - const - a single, standalone constant
111 - enum - defines an integer enumeration, with 111 - enum - defines an integer enumeration, with values for each entry
112 incrementing by 1, (e.g. 0, 1, 2, 3) 112 incrementing by 1, (e.g. 0, 1, 2, 3)
113 - flags - defines an integer enumeration, wit 113 - flags - defines an integer enumeration, with values for each entry
114 occupying a bit, starting from bit 0, (e.g. 114 occupying a bit, starting from bit 0, (e.g. 1, 2, 4, 8)
115 115
116 value 116 value
117 ~~~~~ 117 ~~~~~
118 118
119 The value for the ``const``. 119 The value for the ``const``.
120 120
121 value-start 121 value-start
122 ~~~~~~~~~~~ 122 ~~~~~~~~~~~
123 123
124 The first value for ``enum`` and ``flags``, al 124 The first value for ``enum`` and ``flags``, allows overriding the default
125 start value of ``0`` (for ``enum``) and starti 125 start value of ``0`` (for ``enum``) and starting bit (for ``flags``).
126 For ``flags`` ``value-start`` selects the star 126 For ``flags`` ``value-start`` selects the starting bit, not the shifted value.
127 127
128 Sparse enumerations are not supported. 128 Sparse enumerations are not supported.
129 129
130 entries 130 entries
131 ~~~~~~~ 131 ~~~~~~~
132 132
133 Array of names of the entries for ``enum`` and 133 Array of names of the entries for ``enum`` and ``flags``.
134 134
135 header 135 header
136 ~~~~~~ 136 ~~~~~~
137 137
138 For C-compatible languages, header which alrea 138 For C-compatible languages, header which already defines this value.
139 In case the definition is shared by multiple f 139 In case the definition is shared by multiple families (e.g. ``IFNAMSIZ``)
140 code generators for C-compatible languages may 140 code generators for C-compatible languages may prefer to add an appropriate
141 include instead of rendering a new definition. 141 include instead of rendering a new definition.
142 142
143 attribute-sets 143 attribute-sets
144 -------------- 144 --------------
145 145
146 This property contains information about netli 146 This property contains information about netlink attributes of the family.
147 All families have at least one attribute set, 147 All families have at least one attribute set, most have multiple.
148 ``attribute-sets`` is an array, with each entr 148 ``attribute-sets`` is an array, with each entry describing a single set.
149 149
150 Note that the spec is "flattened" and is not m 150 Note that the spec is "flattened" and is not meant to visually resemble
151 the format of the netlink messages (unlike cer 151 the format of the netlink messages (unlike certain ad-hoc documentation
152 formats seen in kernel comments). In the spec 152 formats seen in kernel comments). In the spec subordinate attribute sets
153 are not defined inline as a nest, but defined 153 are not defined inline as a nest, but defined in a separate attribute set
154 referred to with a ``nested-attributes`` prope 154 referred to with a ``nested-attributes`` property of the container.
155 155
156 Spec may also contain fractional sets - sets w 156 Spec may also contain fractional sets - sets which contain a ``subset-of``
157 property. Such sets describe a section of a fu 157 property. Such sets describe a section of a full set, allowing narrowing down
158 which attributes are allowed in a nest or refi 158 which attributes are allowed in a nest or refining the validation criteria.
159 Fractional sets can only be used in nests. The 159 Fractional sets can only be used in nests. They are not rendered to the uAPI
160 in any fashion. 160 in any fashion.
161 161
162 name 162 name
163 ~~~~ 163 ~~~~
164 164
165 Uniquely identifies the attribute set, operati 165 Uniquely identifies the attribute set, operations and nested attributes
166 refer to the sets by the ``name``. 166 refer to the sets by the ``name``.
167 167
168 subset-of 168 subset-of
169 ~~~~~~~~~ 169 ~~~~~~~~~
170 170
171 Re-defines a portion of another set (a fractio 171 Re-defines a portion of another set (a fractional set).
172 Allows narrowing down fields and changing vali 172 Allows narrowing down fields and changing validation criteria
173 or even types of attributes depending on the n 173 or even types of attributes depending on the nest in which they
174 are contained. The ``value`` of each attribute 174 are contained. The ``value`` of each attribute in the fractional
175 set is implicitly the same as in the main set. 175 set is implicitly the same as in the main set.
176 176
177 attributes 177 attributes
178 ~~~~~~~~~~ 178 ~~~~~~~~~~
179 179
180 List of attributes in the set. 180 List of attributes in the set.
181 181
182 .. _attribute_properties: 182 .. _attribute_properties:
183 183
184 Attribute properties 184 Attribute properties
185 -------------------- 185 --------------------
186 186
187 name 187 name
188 ~~~~ 188 ~~~~
189 189
190 Identifies the attribute, unique within the se 190 Identifies the attribute, unique within the set.
191 191
192 type 192 type
193 ~~~~ 193 ~~~~
194 194
195 Netlink attribute type, see :ref:`attr_types`. 195 Netlink attribute type, see :ref:`attr_types`.
196 196
197 .. _assign_val: 197 .. _assign_val:
198 198
199 value 199 value
200 ~~~~~ 200 ~~~~~
201 201
202 Numerical attribute ID, used in serialized Net 202 Numerical attribute ID, used in serialized Netlink messages.
203 The ``value`` property can be skipped, in whic 203 The ``value`` property can be skipped, in which case the attribute ID
204 will be the value of the previous attribute pl 204 will be the value of the previous attribute plus one (recursively)
205 and ``1`` for the first attribute in the attri 205 and ``1`` for the first attribute in the attribute set.
206 206
207 Attributes (and operations) use ``1`` as the d 207 Attributes (and operations) use ``1`` as the default value for the first
208 entry (unlike enums in definitions which start 208 entry (unlike enums in definitions which start from ``0``) because
209 entry ``0`` is almost always reserved as undef 209 entry ``0`` is almost always reserved as undefined. Spec can explicitly
210 set value to ``0`` if needed. 210 set value to ``0`` if needed.
211 211
212 Note that the ``value`` of an attribute is def 212 Note that the ``value`` of an attribute is defined only in its main set
213 (not in subsets). 213 (not in subsets).
214 214
215 enum 215 enum
216 ~~~~ 216 ~~~~
217 217
218 For integer types specifies that values in the 218 For integer types specifies that values in the attribute belong
219 to an ``enum`` or ``flags`` from the ``definit 219 to an ``enum`` or ``flags`` from the ``definitions`` section.
220 220
221 enum-as-flags 221 enum-as-flags
222 ~~~~~~~~~~~~~ 222 ~~~~~~~~~~~~~
223 223
224 Treat ``enum`` as ``flags`` regardless of its 224 Treat ``enum`` as ``flags`` regardless of its type in ``definitions``.
225 When both ``enum`` and ``flags`` forms are nee 225 When both ``enum`` and ``flags`` forms are needed ``definitions`` should
226 contain an ``enum`` and attributes which need 226 contain an ``enum`` and attributes which need the ``flags`` form should
227 use this attribute. 227 use this attribute.
228 228
229 nested-attributes 229 nested-attributes
230 ~~~~~~~~~~~~~~~~~ 230 ~~~~~~~~~~~~~~~~~
231 231
232 Identifies the attribute space for attributes 232 Identifies the attribute space for attributes nested within given attribute.
233 Only valid for complex attributes which may ha 233 Only valid for complex attributes which may have sub-attributes.
234 234
235 multi-attr (arrays) 235 multi-attr (arrays)
236 ~~~~~~~~~~~~~~~~~~~ 236 ~~~~~~~~~~~~~~~~~~~
237 237
238 Boolean property signifying that the attribute 238 Boolean property signifying that the attribute may be present multiple times.
239 Allowing an attribute to repeat is the recomme 239 Allowing an attribute to repeat is the recommended way of implementing arrays
240 (no extra nesting). 240 (no extra nesting).
241 241
242 byte-order 242 byte-order
243 ~~~~~~~~~~ 243 ~~~~~~~~~~
244 244
245 For integer types specifies attribute byte ord 245 For integer types specifies attribute byte order - ``little-endian``
246 or ``big-endian``. 246 or ``big-endian``.
247 247
248 checks 248 checks
249 ~~~~~~ 249 ~~~~~~
250 250
251 Input validation constraints used by the kerne 251 Input validation constraints used by the kernel. User space should query
252 the policy of the running kernel using Generic 252 the policy of the running kernel using Generic Netlink introspection,
253 rather than depend on what is specified in the 253 rather than depend on what is specified in the spec file.
254 254
255 The validation policy in the kernel is formed 255 The validation policy in the kernel is formed by combining the type
256 definition (``type`` and ``nested-attributes`` 256 definition (``type`` and ``nested-attributes``) and the ``checks``.
257 257
258 sub-type 258 sub-type
259 ~~~~~~~~ 259 ~~~~~~~~
260 260
261 Legacy families have special ways of expressin 261 Legacy families have special ways of expressing arrays. ``sub-type`` can be
262 used to define the type of array members in ca 262 used to define the type of array members in case array members are not
263 fully defined as attributes (in a bona fide at 263 fully defined as attributes (in a bona fide attribute space). For instance
264 a C array of u32 values can be specified with 264 a C array of u32 values can be specified with ``type: binary`` and
265 ``sub-type: u32``. Binary types and legacy arr 265 ``sub-type: u32``. Binary types and legacy array formats are described in
266 more detail in :doc:`genetlink-legacy`. 266 more detail in :doc:`genetlink-legacy`.
267 267
268 display-hint 268 display-hint
269 ~~~~~~~~~~~~ 269 ~~~~~~~~~~~~
270 270
271 Optional format indicator that is intended onl 271 Optional format indicator that is intended only for choosing the right
272 formatting mechanism when displaying values of 272 formatting mechanism when displaying values of this type. Currently supported
273 hints are ``hex``, ``mac``, ``fddi``, ``ipv4`` 273 hints are ``hex``, ``mac``, ``fddi``, ``ipv4``, ``ipv6`` and ``uuid``.
274 274
275 operations 275 operations
276 ---------- 276 ----------
277 277
278 This section describes messages passed between 278 This section describes messages passed between the kernel and the user space.
279 There are three types of entries in this secti 279 There are three types of entries in this section - operations, notifications
280 and events. 280 and events.
281 281
282 Operations describe the most common request - 282 Operations describe the most common request - response communication. User
283 sends a request and kernel replies. Each opera 283 sends a request and kernel replies. Each operation may contain any combination
284 of the two modes familiar to netlink users - ` 284 of the two modes familiar to netlink users - ``do`` and ``dump``.
285 ``do`` and ``dump`` in turn contain a combinat 285 ``do`` and ``dump`` in turn contain a combination of ``request`` and
286 ``response`` properties. If no explicit messag 286 ``response`` properties. If no explicit message with attributes is passed
287 in a given direction (e.g. a ``dump`` which do 287 in a given direction (e.g. a ``dump`` which does not accept filter, or a ``do``
288 of a SET operation to which the kernel respond 288 of a SET operation to which the kernel responds with just the netlink error
289 code) ``request`` or ``response`` section can 289 code) ``request`` or ``response`` section can be skipped.
290 ``request`` and ``response`` sections list the 290 ``request`` and ``response`` sections list the attributes allowed in a message.
291 The list contains only the names of attributes 291 The list contains only the names of attributes from a set referred
292 to by the ``attribute-set`` property. 292 to by the ``attribute-set`` property.
293 293
294 Notifications and events both refer to the asy 294 Notifications and events both refer to the asynchronous messages sent by
295 the kernel to members of a multicast group. Th 295 the kernel to members of a multicast group. The difference between the
296 two is that a notification shares its contents 296 two is that a notification shares its contents with a GET operation
297 (the name of the GET operation is specified in 297 (the name of the GET operation is specified in the ``notify`` property).
298 This arrangement is commonly used for notifica 298 This arrangement is commonly used for notifications about
299 objects where the notification carries the ful 299 objects where the notification carries the full object definition.
300 300
301 Events are more focused and carry only a subse 301 Events are more focused and carry only a subset of information rather than full
302 object state (a made up example would be a lin 302 object state (a made up example would be a link state change event with just
303 the interface name and the new link state). Ev 303 the interface name and the new link state). Events contain the ``event``
304 property. Events are considered less idiomatic 304 property. Events are considered less idiomatic for netlink and notifications
305 should be preferred. 305 should be preferred.
306 306
307 list 307 list
308 ~~~~ 308 ~~~~
309 309
310 The only property of ``operations`` for ``gene 310 The only property of ``operations`` for ``genetlink``, holds the list of
311 operations, notifications etc. 311 operations, notifications etc.
312 312
313 Operation properties 313 Operation properties
314 -------------------- 314 --------------------
315 315
316 name 316 name
317 ~~~~ 317 ~~~~
318 318
319 Identifies the operation. 319 Identifies the operation.
320 320
321 value 321 value
322 ~~~~~ 322 ~~~~~
323 323
324 Numerical message ID, used in serialized Netli 324 Numerical message ID, used in serialized Netlink messages.
325 The same enumeration rules are applied as to 325 The same enumeration rules are applied as to
326 :ref:`attribute values<assign_val>`. 326 :ref:`attribute values<assign_val>`.
327 327
328 attribute-set 328 attribute-set
329 ~~~~~~~~~~~~~ 329 ~~~~~~~~~~~~~
330 330
331 Specifies the attribute set contained within t 331 Specifies the attribute set contained within the message.
332 332
333 do 333 do
334 ~~~ 334 ~~~
335 335
336 Specification for the ``doit`` request. Should 336 Specification for the ``doit`` request. Should contain ``request``, ``reply``
337 or both of these properties, each holding a :r 337 or both of these properties, each holding a :ref:`attr_list`.
338 338
339 dump 339 dump
340 ~~~~ 340 ~~~~
341 341
342 Specification for the ``dumpit`` request. Shou 342 Specification for the ``dumpit`` request. Should contain ``request``, ``reply``
343 or both of these properties, each holding a :r 343 or both of these properties, each holding a :ref:`attr_list`.
344 344
345 notify 345 notify
346 ~~~~~~ 346 ~~~~~~
347 347
348 Designates the message as a notification. Cont 348 Designates the message as a notification. Contains the name of the operation
349 (possibly the same as the operation holding th 349 (possibly the same as the operation holding this property) which shares
350 the contents with the notification (``do``). 350 the contents with the notification (``do``).
351 351
352 event 352 event
353 ~~~~~ 353 ~~~~~
354 354
355 Specification of attributes in the event, hold 355 Specification of attributes in the event, holds a :ref:`attr_list`.
356 ``event`` property is mutually exclusive with 356 ``event`` property is mutually exclusive with ``notify``.
357 357
358 mcgrp 358 mcgrp
359 ~~~~~ 359 ~~~~~
360 360
361 Used with ``event`` and ``notify``, specifies 361 Used with ``event`` and ``notify``, specifies which multicast group
362 message belongs to. 362 message belongs to.
363 363
364 .. _attr_list: 364 .. _attr_list:
365 365
366 Message attribute list 366 Message attribute list
367 ---------------------- 367 ----------------------
368 368
369 ``request``, ``reply`` and ``event`` propertie 369 ``request``, ``reply`` and ``event`` properties have a single ``attributes``
370 property which holds the list of attribute nam 370 property which holds the list of attribute names.
371 371
372 Messages can also define ``pre`` and ``post`` 372 Messages can also define ``pre`` and ``post`` properties which will be rendered
373 as ``pre_doit`` and ``post_doit`` calls in the 373 as ``pre_doit`` and ``post_doit`` calls in the kernel (these properties should
374 be ignored by user space). 374 be ignored by user space).
375 375
376 mcast-groups 376 mcast-groups
377 ------------ 377 ------------
378 378
379 This section lists the multicast groups of the 379 This section lists the multicast groups of the family.
380 380
381 list 381 list
382 ~~~~ 382 ~~~~
383 383
384 The only property of ``mcast-groups`` for ``ge 384 The only property of ``mcast-groups`` for ``genetlink``, holds the list
385 of groups. 385 of groups.
386 386
387 Multicast group properties 387 Multicast group properties
388 -------------------------- 388 --------------------------
389 389
390 name 390 name
391 ~~~~ 391 ~~~~
392 392
393 Uniquely identifies the multicast group in the 393 Uniquely identifies the multicast group in the family. Similarly to
394 Family ID, Multicast Group ID needs to be reso 394 Family ID, Multicast Group ID needs to be resolved at runtime, based
395 on the name. 395 on the name.
396 396
397 .. _attr_types: 397 .. _attr_types:
398 398
399 Attribute types 399 Attribute types
400 =============== 400 ===============
401 401
402 This section describes the attribute types sup 402 This section describes the attribute types supported by the ``genetlink``
403 compatibility level. Refer to documentation of 403 compatibility level. Refer to documentation of different levels for additional
404 attribute types. 404 attribute types.
405 405
406 Common integer types 406 Common integer types
407 -------------------- 407 --------------------
408 408
409 ``sint`` and ``uint`` represent signed and uns 409 ``sint`` and ``uint`` represent signed and unsigned 64 bit integers.
410 If the value can fit on 32 bits only 32 bits a 410 If the value can fit on 32 bits only 32 bits are carried in netlink
411 messages, otherwise full 64 bits are carried. 411 messages, otherwise full 64 bits are carried. Note that the payload
412 is only aligned to 4B, so the full 64 bit valu 412 is only aligned to 4B, so the full 64 bit value may be unaligned!
413 413
414 Common integer types should be preferred over 414 Common integer types should be preferred over fix-width types in majority
415 of cases. 415 of cases.
416 416
417 Fix-width integer types 417 Fix-width integer types
418 ----------------------- 418 -----------------------
419 419
420 Fixed-width integer types include: 420 Fixed-width integer types include:
421 ``u8``, ``u16``, ``u32``, ``u64``, ``s8``, ``s 421 ``u8``, ``u16``, ``u32``, ``u64``, ``s8``, ``s16``, ``s32``, ``s64``.
422 422
423 Note that types smaller than 32 bit should be 423 Note that types smaller than 32 bit should be avoided as using them
424 does not save any memory in Netlink messages ( 424 does not save any memory in Netlink messages (due to alignment).
425 See :ref:`pad_type` for padding of 64 bit attr 425 See :ref:`pad_type` for padding of 64 bit attributes.
426 426
427 The payload of the attribute is the integer in 427 The payload of the attribute is the integer in host order unless ``byte-order``
428 specifies otherwise. 428 specifies otherwise.
429 429
430 64 bit values are usually aligned by the kerne 430 64 bit values are usually aligned by the kernel but it is recommended
431 that the user space is able to deal with unali 431 that the user space is able to deal with unaligned values.
432 432
433 .. _pad_type: 433 .. _pad_type:
434 434
435 pad 435 pad
436 --- 436 ---
437 437
438 Special attribute type used for padding attrib 438 Special attribute type used for padding attributes which require alignment
439 bigger than standard 4B alignment required by 439 bigger than standard 4B alignment required by netlink (e.g. 64 bit integers).
440 There can only be a single attribute of the `` 440 There can only be a single attribute of the ``pad`` type in any attribute set
441 and it should be automatically used for paddin 441 and it should be automatically used for padding when needed.
442 442
443 flag 443 flag
444 ---- 444 ----
445 445
446 Attribute with no payload, its presence is the 446 Attribute with no payload, its presence is the entire information.
447 447
448 binary 448 binary
449 ------ 449 ------
450 450
451 Raw binary data attribute, the contents are op 451 Raw binary data attribute, the contents are opaque to generic code.
452 452
453 string 453 string
454 ------ 454 ------
455 455
456 Character string. Unless ``checks`` has ``unte 456 Character string. Unless ``checks`` has ``unterminated-ok`` set to ``true``
457 the string is required to be null terminated. 457 the string is required to be null terminated.
458 ``max-len`` in ``checks`` indicates the longes 458 ``max-len`` in ``checks`` indicates the longest possible string,
459 if not present the length of the string is unb 459 if not present the length of the string is unbounded.
460 460
461 Note that ``max-len`` does not count the termi 461 Note that ``max-len`` does not count the terminating character.
462 462
463 nest 463 nest
464 ---- 464 ----
465 465
466 Attribute containing other (nested) attributes 466 Attribute containing other (nested) attributes.
467 ``nested-attributes`` specifies which attribut 467 ``nested-attributes`` specifies which attribute set is used inside.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.