netlink.rst 3.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102
  1. .. SPDX-License-Identifier: BSD-3-Clause
  2. .. _kernel_netlink:
  3. ===================================
  4. Netlink notes for kernel developers
  5. ===================================
  6. General guidance
  7. ================
  8. Attribute enums
  9. ---------------
  10. Older families often define "null" attributes and commands with value
  11. of ``0`` and named ``unspec``. This is supported (``type: unused``)
  12. but should be avoided in new families. The ``unspec`` enum values are
  13. not used in practice, so just set the value of the first attribute to ``1``.
  14. Message enums
  15. -------------
  16. Use the same command IDs for requests and replies. This makes it easier
  17. to match them up, and we have plenty of ID space.
  18. Use separate command IDs for notifications. This makes it easier to
  19. sort the notifications from replies (and present them to the user
  20. application via a different API than replies).
  21. Answer requests
  22. ---------------
  23. Older families do not reply to all of the commands, especially NEW / ADD
  24. commands. User only gets information whether the operation succeeded or
  25. not via the ACK. Try to find useful data to return. Once the command is
  26. added whether it replies with a full message or only an ACK is uAPI and
  27. cannot be changed. It's better to err on the side of replying.
  28. Specifically NEW and ADD commands should reply with information identifying
  29. the created object such as the allocated object's ID (without having to
  30. resort to using ``NLM_F_ECHO``).
  31. NLM_F_ECHO
  32. ----------
  33. Make sure to pass the request info to genl_notify() to allow ``NLM_F_ECHO``
  34. to take effect. This is useful for programs that need precise feedback
  35. from the kernel (for example for logging purposes).
  36. Support dump consistency
  37. ------------------------
  38. If iterating over objects during dump may skip over objects or repeat
  39. them - make sure to report dump inconsistency with ``NLM_F_DUMP_INTR``.
  40. This is usually implemented by maintaining a generation id for the
  41. structure and recording it in the ``seq`` member of struct netlink_callback.
  42. Netlink specification
  43. =====================
  44. Documentation of the Netlink specification parts which are only relevant
  45. to the kernel space.
  46. Globals
  47. -------
  48. kernel-policy
  49. ~~~~~~~~~~~~~
  50. Defines whether the kernel validation policy is ``global`` i.e. the same for all
  51. operations of the family, defined for each operation individually - ``per-op``,
  52. or separately for each operation and operation type (do vs dump) - ``split``.
  53. New families should use ``per-op`` (default) to be able to narrow down the
  54. attributes accepted by a specific command.
  55. checks
  56. ------
  57. Documentation for the ``checks`` sub-sections of attribute specs.
  58. unterminated-ok
  59. ~~~~~~~~~~~~~~~
  60. Accept strings without the null-termination (for legacy families only).
  61. Switches from the ``NLA_NUL_STRING`` to ``NLA_STRING`` policy type.
  62. max-len
  63. ~~~~~~~
  64. Defines max length for a binary or string attribute (corresponding
  65. to the ``len`` member of struct nla_policy). For string attributes terminating
  66. null character is not counted towards ``max-len``.
  67. The field may either be a literal integer value or a name of a defined
  68. constant. String types may reduce the constant by one
  69. (i.e. specify ``max-len: CONST - 1``) to reserve space for the terminating
  70. character so implementations should recognize such pattern.
  71. min-len
  72. ~~~~~~~
  73. Similar to ``max-len`` but defines minimum length.