linux模块和进程,Linux 内核模块的运行环境与传统进程间通信 [zt]

自由软件爱好者,南京邮电学院电子工程系2004年7月

多数的Linux内核态程序都需要和用户空间的进程交换数据，但Linux内核态无法对传统的Linux进程间同步和通信的方法提供足够的支持。本文总结并比较了几种内核态与用户态进程通信的实现方法，并推荐使用netlink套接字实现中断环境与用户态进程通信。

引言Linux是一个源码开放的操作系统，无论是普通用户还是企业用户都可以编写自己的内核代码，再加上对标准内核的裁剪从而制作出适合自己的操作系统。目前有很多中低端用户使用的网络设备的操作系统是从标准Linux改进而来的，这也说明了有越来越多的人正在加入到Linux内核开发团体中。

一个或多个内核模块的实现并不能满足一般Linux系统软件的需要，因为内核的局限性太大，如不能在终端上打印，不能做大延时的处理等等。当我们需要做这些的时候，就需要将在内核态采集到的数据传送到用户态的一个或多个进程中进行处理。这样，内核态与用户空间进程通信的方法就显得尤为重要。在Linux的内核发行版本中没有对该类通信方法的详细介绍，也没有其他文章对此进行总结，所以本文将列举几种内核态与用户态进程通信的方法并详细分析它们的实现和适用环境。

内核模块的运行环境与传统进程间通信在一台运行Linux的计算机中，CPU在任何时候只会有如下四种状态：

【1】在处理一个硬中断。

【2】在处理一个软中断，如softirq、tasklet和bh。

【3】运行于内核态，但有进程上下文，即与一个进程相关。

【4】运行一个用户态进程。

其中，【1】、【2】和【3】是运行于内核空间的，而【4】是在用户空间。其中除了【4】，其他状态只可以被在其之上的状态抢占。比如，软中断只可以被硬中断抢占。

Linux内核模块是一段可以动态在内核装载和卸载的代码，装载进内核的代码便立即在内核中工作起来。Linux内核代码的运行环境有三种：用户上下文环境、硬中断环境和软中断环境。但三种环境的局限性分两种，因为软中断环境只是硬中断环境的延续。比较如表【1】。

<><><><><><>内核态环境

介绍

局限性

用户上下文

内核态代码的运行与一用户空间进程相关，如系统调用中代码的运行环境。

不可直接将本地变量传递给用户态的内存区，因为内核态和用户态的内存映射机制不同。

硬中断和软中断环境

硬中断或软中断过程中代码的运行环境，如IP数据报的接收代码的运行环境，网络设备的驱动程序等。

不可直接向用户态内存区传递数据；代码在运行过程中不可阻塞。

Linux传统的进程间通信有很多，如各类管道、消息队列、内存共享、信号量等等。但它们都无法介于内核态与用户态使用，原因如表【2】。

表【2】

<><>通信方法

无法介于内核态与用户态的原因

管道(不包括命名管道)

局限于父子进程间的通信。

消息队列

在硬、软中断中无法无阻塞地接收数据。

信号量

无法介于内核态和用户态使用。

内存共享

需要信号量辅助，而信号量又无法使用。

套接字

在硬、软中断中无法无阻塞地接收数据。

内核态与用户态进程通信方法的提出与实现

．1用户上下文环境运行在用户上下文环境中的代码是可以阻塞的，这样，便可以使用消息队列和UNIX域套接字来实现内核态与用户态的通信。但这些方法的数据传输效率较低，Linux内核提供copy_from_user()/copy_to_user()函数来实现内核态与用户态数据的拷贝，但这两个函数会引发阻塞，所以不能用在硬、软中断中。一般将这两个特殊拷贝函数用在类似于系统调用一类的函数中，此类函数在使用中往往"穿梭"于内核态与用户态。此类方法的工作原理路如图【1】。

其中相关的系统调用是需要用户自行编写并载入内核。 imp1.h是通用头文件，定义了用户态和内核态都要用到的宏。imp1_k.c是内核模块的源代码。imp1_u.c是用户态进程的源代码。整个示例演示了由一个用户态进程向用户上下文环境发送一个字符串，内容为"a message from userspace\n"。然后再由用户上下文环境向用户态进程发送一个字符串，内容为"a message from kernel\n"。

．2硬、软中断环境比起用户上下文环境，硬中断和软中断环境与用户态进程无丝毫关系，而且运行过程不能阻塞。

3．2．1使用一般进程间通信的方法

我们无法直接使用传统的进程间通信的方法实现。但硬、软中断中也有一套同步机制--自旋锁(spinlock)，可以通过自旋锁来实现中断环境与中断环境，中断环境与内核线程的同步，而内核线程是运行在有进程上下文环境中的，这样便可以在内核线程中使用套接字或消息队列来取得用户空间的数据，然后再将数据通过临界区传递给中断过程。基本思路如图【2】。

因为中断过程不可能无休止地等待用户态进程发送数据，所以要通过一个内核线程来接收用户空间的数据，再通过临界区传给中断过程。中断过程向用户空间的数据发送必须是无阻塞的。这样的通信模型并不令人满意，因为内核线程是和其他用户态进程竞争CPU接收数据的，效率很低，这样中断过程便不能实时地接收来自用户空间的数据。

3．2．2 netlink套接字

在Linux 2.4版以后版本的内核中，几乎全部的中断过程与用户态进程的通信都是使用netlink套接字实现的，同时还使用netlink实现了ip queue工具，但ip queue的使用有其局限性，不能自由地用于各种中断过程。内核的帮助文档和其他一些Linux相关文章都没有对netlink套接字在中断过程和用户空间通信的应用上作详细的说明，使得很多用户对此只有一个模糊的概念。

netlink套接字的通信依据是一个对应于进程的标识，一般定为该进程的ID。当通信的一端处于中断过程时，该标识为0。当使用netlink套接字进行通信，通信的双方都是用户态进程，则使用方法类似于消息队列。但通信双方有一端是中断过程，使用方法则不同。netlink套接字的最大特点是对中断过程的支持，它在内核空间接收用户空间数据时不再需要用户自行启动一个内核线程，而是通过另一个软中断调用用户事先指定的接收函数。工作原理如图【3】。

很明显，这里使用了软中断而不是内核线程来接收数据，这样就可以保证数据接收的实时性。

当netlink套接字用于内核空间与用户空间的通信时，在用户空间的创建方法和一般套接字使用类似，但内核空间的创建方法则不同。图【4】是netlink套接字实现此类通信时创建的过程。

以下举一个netlink套接字的应用示例。示例实现了从netfilter的NF_IP_PRE_ROUTING点截获的ICMP数据报，在将数据报的相关信息传递到一个用户态进程，由用户态进程将信息打印在终端上。源码在文件

static struct sock *nlfd;

struct

{

__u32 pid;

rwlock_t lock;

}user_proc;

/*挂接在netfilter框架的NF_IP_PRE_ROUTING点上的函数为get_icmp()*/

static struct nf_hook_ops imp2_ops =

{

.hook = get_icmp,/*netfilter钩子函数*/

.pf = PF_INET,

.hooknum = NF_IP_PRE_ROUTING,

.priority = NF_IP_PRI_FILTER -1,

};

static int __init init(void)

{

rwlock_init(&user_proc.lock);

/*在内核创建一个netlink socket，并注明由kernel_recieve()函数接收数据

这里协议NL_IMP2是自定的*/

nlfd = netlink_kernel_create(NL_IMP2, kernel_receive);

if(!nlfd)

{

printk("can not create a netlink socket\n");

return -1;

}

/*向netfilter的NF_IP_PRE_ROUTING点挂接函数*/

return nf_register_hook(&imp2_ops);

}

static void __exit fini(void)

{

if(nlfd)

{

sock_release(nlfd->socket);

}

nf_unregister_hook(&imp2_ops);

}

module_init(init);

module_exit(fini);

其实片断(一)的工作很简单，模块加载阶段先在内核空间创建一个netlink套接字，再将一个函数挂接在netfilter框架的NF_IP_PRE_ROUTING钩子点上。卸载时释放套接字所占的资源并注销之前在netfilter上挂接的函数。

DECLARE_MUTEX(receive_sem);

01:static void kernel_receive(struct sock *sk, int len)

02:{

03: do

04:{

05: struct sk_buff *skb;

06:if(down_trylock(&receive_sem))

07:return;

08:

09:while((skb = skb_dequeue(&sk->sk_receive_queue))!=NULL)

10:{

11:{

12:struct nlmsghdr *nlh = NULL;

13:if(skb->len >= sizeof(struct nlmsghdr)

14:{

15:    nlh = (struct nlmsghdr *)skb->data;

16:    if((nlh->nlmsg_len >= sizeof(struct nlmsghdr))

17:    && (skb->len >= nlh-> nlmsg_len))

18:    {

19:        if(nlh-> nlmsg_type == IM2_U_PID)

20:        {

21:            write_lock_bh(&user_proc.pid);

22:            user_proc.pid = nlh-> nlmsg_pid;

23:             write_unlock_bh(&user_proc.pid);

24:        }

25:        else if(nlh -> nlmsg_type == IMP2_CLOSE)

26:        {

27:            write_lock_bh(&user_proc.pid);

28:            if(nlh -> nlmsg_pid == user_proc.pid)

user_proc.pid = 0;

29:            write_unlock_bh(&user_proc.pid);

30:}

31:       }

32:    }

33:}

34:kfree_skb(skb);

35:}

36:up(&receive_sem);

37:}while(nlfd && nlfd -> sk_receive_queue.qlen);

38:}

如果读者看过ip_queue.c或rtnetlink.c中的源码会发现片断(二)中的03～18和31～38是netlink socket在内核空间接收数据的框架。在框架中主要是从套接字缓存中取出全部的数据，然后分析是不是合法的数据报，合法的netlink数据报必须有nlmsghdr结构的报头。在这里笔者使用了自己定义的消息类型：IMP2_U_PID(消息为用户空间进程的ID)，IMP2_CLOSE(用户空间进程关闭)。因为考虑到SMP，所以在这里使用了读写锁来避免不同CPU访问临界区的问题。kernel_receive()函数的运行在软中断环境。