开发和维护内核是一件很繁杂的工作，因此，只有那些最重要或者与系统性能息息相关的代码才将其安排在内核中。其它程序，比如GUI，管理以及控制部分的代 码，一般都会作为用户态程序。在linux系统中，把系统的某个特性分割成在内核中和在用户空间中分别实现一部分的做法是很常见的(比如linux系统的 防火墙就分成了内核态的Netfilter和用户态的iptables)。然而，内核程序与用户态的程序又是怎样行通讯的呢？
答案就是通过各种各样的用户态和内核态的IPC(interprocess communication )机制来实现。比如系统调用，ioctl接口，proc文件系统以及netlink socket,本文就是要讨论netlink socekt并向读者展示这种用网络
通讯接口方式实现的IPC机制的优点。
介绍：
netlink socekt是一种用于在内核态和用户态进程之间进行数据传输的特殊的IPC。它通过为内核模块提
供一组特殊的API，并为用户程序提供了一组标准的socket 接口的方式，实现了一种全双工的通讯连接。类似于TCP/IP中使用AF_INET地址族一样，netlink socket使用地址族AF_NETLINK。每一个netlink
socket在内核头文件
中定义自己的协议类型。
下面是netlink socket 目前的特性集合以及它支持的协议类型：
| NETLINK_ROUTE 用户空间的路由守护程序之间的通讯通道，比如BGP,OSPF,RIP以及内核数据转发模块。用户态的路由守护程序通过此类型的协议来更新内核中的路由表。 NETLINK_FIREWALL:接收IPV4防火墙代码发送的数据包。 NETLINK_NFLOG:用户态的iptables管理工具和内核中的netfilter模块之间通讯的通道。 NETLINK_ARPD:用来从用户空间管理内核中的ARP表。 |
为什么以上的功能在实现用户程序和内核程序通讯时，都使用netlink方法而不是系统调用，ioctls
或者proc文件系统呢？原因在于：为新的特性添加一个新的系统调用,ioctls或者一个proc文件的做法并不是很容易的一件事情，因为我们要冒着污染内核代码并且可能破坏系统稳定性的风险去完成这件事情。
然而，netlink socket却是如此的简单，你只需要在文件netlink.h中添加一个常量来标识你的协议类型，然后，内核模块和用户程序就可以立刻使用socket风格的API进行通讯了！
Netlink提供了一种异步通讯方式，与其他socket API一样，它提供了一个socket队列来缓冲或者平滑
瞬时的消息高峰。发送netlink消息的系统调用在把消息加入到接收者的消息对列后，会触发接收者的接收处理函数。接收者在接收处理函数上下文中，可以 决定立即处理消息还是把消息放在队列中，在以后其它上下文去处理它(因为我们希望接收处理函数执行的尽可能快)。系统调用与netlink不同，它需要一 个同步的处理，因此，当我们使用一个系统调用来从用户态传递消息到内核时，如果处理这个消息的时间很长的话，内核调度的粒度就会受到影响。
内核中实现系统调用的代码都是在编译时静态链接到内核的，因此，在动态加载模块中去包含一个系统调用的做法是不合适的，那是大多数设备驱动的做法。 使用netlink socket时,动态加载模块中的netlink程序不会和linux内核中的netlink部分产生任何编译时依赖关系。
Netlink优于系统调用，ioctls和proc文件系统的另外一个特点就是它支持多点传送。一个进程可以把消息传输给一个netlink组地址，然 后任意多个进程都可以监听那个组地址(并且接收消息)。这种机制为内核到用户态的事件分发提供了一种近乎完美的解决方案。
系统调用和ioctl都属于单工方式的IPC，也就是说，这种IPC会话的发起者只能是用户态程序。但是，如果内核有一个紧急的消息想要通知给用户态程序 时，该怎么办呢？如果直接使用这些IPC的话，是没办法做到这点的。通常情况下，应用程序会周期性的轮询内核以获取状态的改变，然而，高频度的轮询势必会 增加系统的负载。Netlink 通过允许内核初始化会话的方式完美的解决了此问题，我们称之为netlink socket的双工特性。
最后，netlink socket提供了一组开发者熟悉的BSD风格的API函数，因此，相对于使用神秘的系统调用API或者ioctl而言，netlink开发培训的费用会更低些。
与BSD的Routing socket的关系
在BSD TCP/IP的协议栈实现中，有一种特殊的socket叫做Routing socket.它的地址族为AF_ROUTE, 协议族为PF_ROUTE, socket类型为SOCK_RAW. 这种Routing socket是用户态进程用来向内核中的路由表增加或者删除路由信息用的。在Linux系统中，netlink socket通过协议类型NETLINK_ROUTE实现了与Routing socket相同的功能，可以说，netlink socket提供了BSD Routing socket功能的超集。
Netlink Socket 的API
标准的socket API函数-
- 都能够被用户态程序直接调用来访问netlink socket.你可以访问man手册来获取这些函数的详细定义。在本文，我们只讨论怎样在netlink socket的上下文中为这些函数选择参数。这些API对于使用TCP/IP socket写过一些简单网络程序的读者来说应该很熟悉了。
使用socket()函数创建一个socket，输入：
| int socket(int domain, int type, int protocol) |
socket域(地址族)是AF_NETLINK,socket的类型是SOCK_RAW或者SOCK_DGRAM,因为netlink是一种面向数据包的服务。
协议类型选择netlink要使用的类型即可。下面是一些预定义的netlink协议类型：
和 NETLINK_IP6_FW.
你同样可以很轻松的在netlink.h中添加自定义的协议类型。
每个netlink协议类型可以定义高达32个多点传输的组。每个组用一个比特位来表示，1<
bind()函数
跟TCP/IP中的socket一样，netlink的bind()函数把一个本地socket地址(源socket地址)与一个打开的socket进行关联，netlink地址结构体如下:
| struct sockaddr_nl { sa_family_t nl_family; /* AF_NETLINK */ unsigned short nl_pad; /* zero */ __u32 nl_pid; /* process pid */ __u32 nl_groups; /* mcast groups mask */ } nladdr; |
当上面的结构体被bind()函数调用时，sockaddr_nl的nl_pid属性的值可以设置为访问netlink socket的当前进程的PID，nl_pid作为这个netlink socket的本地地址。应用程序应该选择一个唯一的32位整数来填充nl_pid的值。
公式一使用进程的PID作为nl_pid的值，如果这个进程只需要一个该类型协议的netlink socket的话，选用进程pid作为nl_pid是一个很自然的做法。
换一种情形，如果一个进程的多个线程想要创建属于各个线程的相同协议类型的netlink socket的话，公式二可以用来为每个线程的netlink socket产生nl_pid值。
采 用这种方法，同一进程的不同线程都能获取属于它们的相同协议类型的不同netlink socket。事实上，即便是在一个单独的线程里，也可能需要创建同一协议类型的多个netlink socket。所以开发人员需要更多聪明才智去创建不同的nl_pid值，然而本文中不会就如何创建多个不同的nl_pid的值进行过多的讨论
如果应用程序想要接收特定协议类型的发往指定多播组的netlink消息的话，所有接收组的比特位应该进行与运算，形成sockaddr_nl的 nl_groups域的值。否则的话，nl_groups应该设置为0，以便应用程序只能够收到发送给它的netlink消息。在填充完结构体 nladdr后，作如下的绑定工作:
| bind(fd, (struct sockaddr*)&nladdr, sizeof(nladdr)); |
发送一个netlink 消息
为了能够把一个netlink消息发送给内核或者别的用户进程，类似于UDP数据包发送的sendmsg()函数一样，我们需要另外一个结构体 struct sockaddr_nl nladdr作为目的地址。如果这个netlink消息是发往内核的话，nl_pid属性和nl_groups属性都应该设置为0。
如果这个消息是发往另外一个进程的单点传输消息，nl_pid应该设置为接收者进程的PID，nl_groups应该设置为0，假设系统中使用了公式1。
如果消息是发往一个或者多个多播组的话，应该用所有目的多播组的比特位与运算形成nl_groups的值。然后我们就可以将netlink地址应用到结构体struct msghdr msg中，供函数sendmsg()来调用：
| struct msghdr msg; msg.msg_name = (void *)&(nladdr); msg.msg_namelen = sizeof(nladdr); |
netlink消息同样也需要它自身的消息头，这样做是为了给所有协议类型的netlink消息提供一个通用的背景。
由于linux内核的netlink部分总是认为在每个netlink消息体中已经包含了下面的消息头，所以每个应用程序在发送netlink消息之前需要提供这个头信息：
| struct nlmsghdr { __u32 nlmsg_len; /* Length of message */ __u16 nlmsg_type; /* Message type*/ __u16 nlmsg_flags; /* Additional flags */ __u32 nlmsg_seq; /* Sequence number */ __u32 nlmsg_pid; /* Sending process PID */ }; |
nlmsg_len 需要用netlink 消息体的总长度来填充，包含头信息在内，这个是netlink核心需要的信息。mlmsg_type可以被应用程序所用，它对于netlink核心来说是 一个透明的值。Nsmsg_flags 用来该对消息体进行另外的控制，会被netlink核心代码读取并更新。Nlmsg_seq和nlmsg_pid同样对于netlink核心部分来说是透 明的，应用程序用它们来跟踪消息。
因此，一个netlink消息体由nlmsghdr和消息的payload部分组成。一旦输入一个消息，它就会进入一个被nlh指针指向的缓冲区。我们同样可以把消息发送个结构体struct msghdr msg:
| struct iovec iov; iov.iov_base = (void *)nlh; iov.iov_len = nlh->nlmsg_len; msg.msg_iov = &iov; msg.msg_iovlen = 1; |
在完成了以上步骤后，调用一次sendmsg()函数就能把netlink消息发送出去：
| sendmsg(fd, &msg, 0); |
接收netlink消息：
接收程序需要申请足够大的空间来存储netlink消息头和消息的payload部分。它会用如下的方式填充结构体 struct msghdr msg,然后使用标准函数接口recvmsg()来接收netlink消息，假设nlh指向缓冲区：
| struct sockaddr_nl nladdr; struct msghdr msg; struct iovec iov; iov.iov_base = (void *)nlh; iov.iov_len = MAX_NL_MSG_LEN; msg.msg_name = (void *)&(nladdr); msg.msg_namelen = sizeof(nladdr); msg.msg_iov = &iov; msg.msg_iovlen = 1; recvmsg(fd, &msg, 0); |
当消息正确接收后，nlh应该指向刚刚接收到的netlink消息的头部分。Nladdr应该包含接收到消息体的目的地信息，这个目的地信息由pid和消 息将要发往的多播组的值组成。Netlink.h中的宏定义NLMSG_DATA(nlh)返回指向netlink消息体的payload的指针。调用
就可以关闭掉fd描述符代表的netlink socket.
内核空间的netlink API接口
内核空间的netlink API是由内核中的netlink核心代码支持的，在net/core/af_netlink.c中实现。从内核的角度来说，API接口与用户空间的 API是不一样的。内核模块通过这些API访问netlink socket并且与用户空间的程序进行通讯。如果你不想使用netlink预定义好的协议类型的话，可以在netlink.h中添加一个自定义的协议类 型。例如，我们可以通过在netlink.h中插入下面的代码行，添加一个测试用的协议类型：
然后，就可以在linux内核的任何部分访问这个协议类型了。
在用户空间，我们通过socket()调用来创建一个netlink socket,但是在内核空间，我们调用如下的API：
参数uint是netlink协议类型，例如NETLINK_TEST。函数指针，input,是netlink socket在收到消息时调用的处理消息的回调函数指针。
在内核创建了一个NETLINK_TEST类型的netlink socket后，无论什么时候，只要用户程序发送一个NETLINK_TEST类型的netlink消息到内核的话，通过 netlink_kernel_create()函数注册的回调函数input()都会被调用。下面是一个实现了消息处理函数input的例子。
| void input (struct sock *sk, int len) { struct sk_buff *skb; struct nlmsghdr *nlh = NULL; u8 *payload = NULL; while ((skb = skb_dequeue(&sk->receive_queue))!= NULL) { /* process netlink message pointed by skb->data */ nlh = (struct nlmsghdr *)skb->data; payload = NLMSG_DATA(nlh); /* process netlink message with header pointed by * nlh and payload pointed by payload */ } } |
回调函数input()是在发送进程的系统调用sendmsg()的上下文被调用的。如果input函数中处理消息很快的话，一切都没有问题。但是如果处 理netlink消息花费很长时间的话，我们则希望把消息的处理部分放在input()函数的外面，因为长时间的消息处理过程可能会阻止其它系统调用进入 内核。取而代之，我们可以牺牲一个内核线程来完成后续的无限的的处理动作。
使用
来接收消息。nl_sk是netlink_kernel_create()函数返回的netlink socket,然后，只需要处理skb->data指针指向的netlink消息就可以了。
这个内核线程会在nl_sk中没有消息的时候睡眠。因此，在回调函数input()中我们要做的事情就是唤醒睡眠的内核线程，像这样的方式:
| void input (struct sock *sk, int len) { wake_up_interruptible(sk->sleep); } |
这就是一个升级版的内核与用户空间的通讯模型，它提高了上下文切换的粒度。
从内核中发送netlink消息
就像从用户空间发送消息一样，内核在发送netlink消息时也需要设置源netlink地址和目的netlink地址。假设结构体struct sk_buff * skb指向存储着要发送的netlink消息的缓冲区，源地址可以这样设置:
| NETLINK_CB(skb).groups = local_groups; NETLINK_CB(skb).pid = 0; /* from kernel */ 目的地址可以这样设置: NETLINK_CB(skb).dst_groups = dst_groups; NETLINK_CB(skb).dst_pid = dst_pid; |
这些信息并不存储在 skb->data中，相反，它们存储在socket缓冲区的netlink控制块skb中.
发送一个单播消息，使用:
| int netlink_unicast(struct sock *ssk, struct sk_buff *skb, u32 pid, int nonblock); |
ssk是by netlink_kernel_create()函数返回的netlink socket, skb->data指向需要发送的netlink消息体，如果使用公式一的话，pid是接收程序的pid，noblock表明当接收缓冲区不可用时 是否应该阻塞还是立即返回一个失败信息。
你同样可以从内核发送一个多播消息。下面的函数同时把一个netlink消息发送给pid指定的进程和group标识的多个组。
| void netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 pid, u32 group, int allocation); |
group的值是接收消息的各个组的比特位进行与运算的结果。Allocation是内核内存的申请类型。通常情况下在中断上下文使用 GFP_ATOMIC,否则使用GFP_KERNEL。这是由于发送多播消息时，API可能需要申请一个或者多个socket缓冲区并进行拷贝所引起的。
从内核空间关闭netlink socket
netlink_kernel_create()函数返回的netlink socket为struct sock *nl_sk，我们可以通过访问下面的API来从内核空间关闭这个netlink socket:
sock_release(nl_sk->socket);
到目前为止，我们已经演示了netlink编程概念的最小代码框架。接着我们会使用NETLINK_TEST协议类型，并且假设它已经被添加到内核头文件 中了。这里列举的内核模块代码只是与netlink相关的，所以，你应该把它插入到一个完整的内核模块代码当中去，这样的完整代码在其它代码中可以找到很 多。
实例:
|
|