内核空间与用户空间通信机制：
1. ioctl
2. netlink
3. 系统调用
4. 内存映射
5. proc方式
netlink相对于其他的通信机制具有以下优点：
1. 使用netlink通过自定义一种新的协议并加入协议族即可通过socket API使用netlink协议完成数据交换，而ioctl和proc文件系统均需要通过程序加入相应的设备或文件。
2. netlink使用socket缓冲队列，是一种异步通信机制，而ioctl是同步通信，如果传输数据量较大会影响系统性能。
3. netlink支持多播，属于一个netlink组的模块和进程都能获得该多播消息。
4. netlink允许内核发起会话，而ioctl和系统调用只能由用户空间发起。
Netlink socket是用户空间程序和内核模块之间一种很灵活的通讯接口。它为应用程序和内核程序都提供了一个方便使用的API。它还提供了高级的通讯特性，比如全双工，缓冲I/O,多点传送和异步通讯，这些都是其他内核/用户态的IPC所不具有的功能。
开发和维护内核是一件很繁杂的工作，因此，只有那些最重要或者与系统性能息息相关的代码才将其安排在内核中。其它程序，比如GUI，管理以及控制部分的代码，一般都会作为用户态程序。在linux系统中，把系统的某个特性分割成在内核中和在用户空间中分别实现一部分的做法是很常见的(比如linux系统的防火墙就分成了内核态的Netfilter和用户态的iptables)。然而，内核程序与用户态的程序又是怎样行通讯的呢？
答案就是通过各种各样的用户态和内核态的IPC(interprocess communication )机制来实现。比如系统调用，ioctl接口，proc文件系统以及netlink socket,本文就是要讨论netlink socekt并向读者展示这种用网络
通讯接口方式实现的IPC机制的优点。
为什么以上的功能在实现用户程序和内核程序通讯时，都使用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功能的超集。
我最近有一个项目需求，需要在linux网卡驱动中加入一个自己的驱动，实现在内核态完成一些报文处理（这个过程可以实现一种零COPY的网络报文截获），对于复杂报文COPY下必要的数据交给用户态来完成（因为过于复杂的报文消耗CPU太大，会导致中断占用时间太长）。因此需要一种内核和用户态配合的通信机制，尝试了很多方式都不太理想，最后采用netlink+内存映射的模式很好的解决了这个问题。Netlink是一种采用socket通信的机制，用于linux内核和上层用户空间进行通信的一种机制，通过实践我认为netlink最大的优点是可以实现“双向通信”，是内核向用户态发起通知的一种最好选择。
内核和用户空间进行通信，大概有如下几种方式可以考虑：
采用内存映射的方式，将内核地址映射到用户态。这种方式最直接，可以适用大量的数据传输机制。这种方式的缺点是很难进行“业务控制”，没有一种可靠的机制保障内核和用户态的调动同步，比如信号量等都不能跨内核、用户层使用。因此内存映射机制一般需要配合一种“消息机制”来控制数据的读取，比如采用“消息”类型的短数据通道来完成一个可靠的数据读取功能。
ioctl机制，ioctl机制可以在驱动中扩展特定的ioctl消息，用于将一些状态从内核反应到用户态。Ioctl有很好的数据同步保护机制，不要担心内核和用户层的数据访问冲突，但是ioctl不适合传输大量的数据，通过和内存映射结合可以很好的完成大量数据交换过程。但是，ioctl的发起方一定是在用户态，因此如果需要内核态主动发起一个通知消息给用户层，则非常的麻烦。可能需要用户态程序采用轮询机制不停的ioctl。
其他一些方式比如系统调用必须通过用户态发起，proc方式不太可靠和实时，用于调试信息的输出还是非常合适的。
通过前面的项目背景，我需要一种可以在内核态主动发起消息的通知方式，而用户态的程序最好可以采用一种“阻塞调用”的方式等待消息。这样的模型可以最大限度的节省CPU的调度，同时可以满足及时处理的要求，最终选择了netlink完成通信的过程。
Netlink的通信模型和socket通信非常相似，主要要点如下：
- netlink采用自己独立的地址编码，struct sockaddr_nl；
- 每个通过netlink发出的消息都必须附带一个netlink自己的消息头，struct nlmsghdr；
- 内核态的netlink的操作API和用户态完全不一样，后面再介绍；
- 用户态的netlink操作完成采用socket函数，非常方便和简单，有TCP/UDP socket编程基础的非常容易上手。