← Previous Lecture  |  Next Lecture →

What You Will Learn

Prerequisites

Before this lecture, you should be comfortable with basic Linux kernel module concepts (insmod, rmmod, printk) and have a general idea of what a socket is from user space network programming. If either of those feels shaky, work through the earlier lectures of our free Linux kernel programming course before continuing here.

What Is a Netlink Socket?

A netlink socket is a Linux-specific socket family — AF_NETLINK — that was created specifically to give a standard, socket-style API for communication between the kernel and user space, and even between kernel subsystems themselves. Unlike a regular TCP/IP socket, netlink traffic never leaves the local machine; it exists purely to move structured messages between kernel code and user space processes without touching the network stack in any meaningful way.

Where a UNIX domain socket identifies its endpoint using a filesystem path, a netlink socket identifies its endpoint using a numeric port ID. In practice, developers commonly reuse the calling process’s PID as the port ID because it is guaranteed to be unique to that process, but conceptually the two values are unrelated — a single process could open multiple netlink sockets, each needing its own distinct port ID.

This bidirectional model is the key difference from most other user-kernel mechanisms. With procfs, sysfs, and debugfs, the user process always has to initiate a read or write — the kernel cannot “push” data on its own. With netlink, the kernel side can send a message to user space at any time, which is exactly why the kernel’s own device-discovery framework (the one behind udev and systemd-udevd) relies on it: whenever a device is plugged in, the kernel needs to proactively notify a waiting daemon, not wait to be polled.

Why the Kernel Itself Uses Netlink

Netlink is not a niche mechanism invented for driver authors — it is the backbone of several major kernel subsystems on any modern Linux 6.x system:

• Networking configuration — tools like ip and ss from the iproute2 suite configure routes, links, and addresses over NETLINK_ROUTE.
• Device hotplug events — udev/systemd-udevd receive device add/remove notifications over NETLINK_KOBJECT_UEVENT.
• Wireless configuration — the nl80211 family drives Wi-Fi driver configuration via generic netlink.
• Firewall and packet filtering — nftables configures netfilter rules over netlink rather than legacy ioctl calls.

Knowing this helps you appreciate why netlink is worth learning as a driver author: if your driver needs to emit asynchronous events to a monitoring daemon, or accept structured configuration from user space, netlink is very often the idiomatic, kernel-native way to do it.

Netlink vs Other User-Kernel Mechanisms

Mechanism	Kernel-Initiated?	Filesystem Footprint	Typical Use
procfs	No	Yes	Debug info, simple read/write
sysfs	No	Yes	Device attributes
debugfs	No	Yes	Driver-internal debugging
ioctl	No	No	Device-specific control ops
netlink	Yes	No	Async events, structured config

Netlink on Modern 6.x Kernels

The core netlink model has stayed remarkably stable since it was introduced, but modern kernels lean much more heavily on generic netlink (genl) rather than raw, hand-rolled netlink families for new subsystems. Generic netlink adds a thin multiplexing layer on top of the classic netlink socket so that many different kernel features can share a single netlink family instead of each needing its own protocol number. When you write a new driver on a 6.x kernel today, generic netlink is usually the recommended starting point rather than requesting a raw protocol number directly — we’ll cover both approaches later in this series so you understand the fundamentals first.

Common Mistakes Beginners Make

• Assuming nl_pid must be the actual process ID — it is a port ID, and any unique value works.
• Forgetting that netlink messages can be dropped under memory pressure — always design your protocol to tolerate loss for non-critical events.
• Using a raw netlink protocol number for a brand-new driver instead of registering under generic netlink, which is the more future-proof approach on modern kernels.

Key Takeaways

Frequently Asked Questions

Q1. Is a netlink socket a real network socket?
No. It uses the standard socket API for convenience, but netlink traffic stays entirely within the local kernel and never touches a network interface.

Q2. Do I need root privileges to use netlink sockets?
It depends on the specific netlink family. Some, like generic user-defined families, can be opened by unprivileged processes; others, like NETLINK_ROUTE configuration operations, require elevated capabilities.

Q3. Can two user space processes communicate using netlink, without any kernel module?
Yes, netlink can be used purely for user-space-to-user-space IPC as well, though this is less common than its user-kernel role.

Q4. Why does udev use netlink instead of a simpler mechanism?
Because device hotplug events are inherently kernel-initiated — the kernel needs to notify user space the moment a device appears, and netlink is the only mechanism among the common options that supports that direction naturally.

Q5. Is netlink still relevant for driver development on kernel 6.x?
Yes. It remains the standard mechanism for asynchronous kernel-to-user notifications and is actively used by core subsystems, though new code is encouraged to use the generic netlink layer.

← Previous Lecture  |  Next Lecture →