Documentation/core-api/netlink.rst

Source file repositories/reference/linux-study-clean/Documentation/core-api/netlink.rst

File Facts

System
Linux kernel
Corpus path
Documentation/core-api/netlink.rst
Extension
.rst
Size
3334 bytes
Lines
103
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: BSD-3-Clause

.. _kernel_netlink:

===================================
Netlink notes for kernel developers
===================================

General guidance
================

Attribute enums
---------------

Older families often define "null" attributes and commands with value
of ``0`` and named ``unspec``. This is supported (``type: unused``)
but should be avoided in new families. The ``unspec`` enum values are
not used in practice, so just set the value of the first attribute to ``1``.

Message enums
-------------

Use the same command IDs for requests and replies. This makes it easier
to match them up, and we have plenty of ID space.

Use separate command IDs for notifications. This makes it easier to
sort the notifications from replies (and present them to the user
application via a different API than replies).

Answer requests
---------------

Older families do not reply to all of the commands, especially NEW / ADD
commands. User only gets information whether the operation succeeded or
not via the ACK. Try to find useful data to return. Once the command is
added whether it replies with a full message or only an ACK is uAPI and
cannot be changed. It's better to err on the side of replying.

Specifically NEW and ADD commands should reply with information identifying
the created object such as the allocated object's ID (without having to
resort to using ``NLM_F_ECHO``).

NLM_F_ECHO
----------

Make sure to pass the request info to genl_notify() to allow ``NLM_F_ECHO``
to take effect.  This is useful for programs that need precise feedback
from the kernel (for example for logging purposes).

Support dump consistency
------------------------

If iterating over objects during dump may skip over objects or repeat
them - make sure to report dump inconsistency with ``NLM_F_DUMP_INTR``.
This is usually implemented by maintaining a generation id for the
structure and recording it in the ``seq`` member of struct netlink_callback.

Netlink specification
=====================

Documentation of the Netlink specification parts which are only relevant
to the kernel space.

Globals
-------

kernel-policy
~~~~~~~~~~~~~

Defines whether the kernel validation policy is ``global`` i.e. the same for all

Annotation

Implementation Notes