用户空间设备驱动2004

原文链接：https://lwn.net/Articles/66829

原文时间：2004年1月20日

原文作者：corbet

Peter Chubb参与Gelato项目的工作，这个项目目标是为了提高IA-64处理器上的Linux性能。 除此之外，Peter还负责对64位扇区的支持工作，这项工作已经合并到2.5内核当中了。在Linux.Conf.Au大会【澳大利亚Linux会议，亚洲太平洋地区规模最大的Linux和开源会议】上，Peter讨论了设备驱动程序。他指出，驱动程序的代码量占到整个内核的50%左右，驱动程序的BUG却占到整个内核的85%左右。驱动程序员一般是硬件工程师，而不是内核黑客。他们要在计划的时间内实现特定功能的内核编程，接口定义比较随意，常常有很多致命的BUG，在开发过程中连常规开发工具都不使用。

如果可以在用户态编写驱动程序，这极大地降低了驱动程序开发和使用的难度。用户态驱动编程不仅可以减少前面提到的内核开发问题，还能建立一套稳定的ABI；用户态驱动框架下的闭源驱动程序可以避开内核对源代码License的要求。用户态驱动程序员可以任意选择自己喜欢的编程语言，甚至是Python语言。

Peter和他供职的公司致力于用户态程序开发成为可能。一些必要的组件已经开发完成。例如，标准Linux允许特权进程访问I/O端口。通过对/dev/mem设备文件做内存映射mmap()，这些特权级进程可以直接访问低地址范围上I/O寄存器。通过另一些接口，例如对/proc文件调用ioctl()，特权进程可以直接访问PCI配置空间。虽然这些功能可以支持少量用户态驱动程序运行，为了支持更多类型的用户态驱动程序还需要开发更多的功能。

在需要考虑的众多功能组件当中，中断是最重要的，也是最有挑战性的。关于用户进程注册和响应设备中断，迄今为止还没有一个好的解决方案。Gelato项目提出在/proc目录下创建一组关于中断的文件。例如，某个进程如果希望处理11号中断，该进程就需要打开/proc/irq/11/irq，然后对返回的文件描述符进行读操作【内核态的处理应该是，中断使能然后等待中断发生】；因此该进程就会在中断发生之前被内核阻塞住，直到中断发生从内核态返回后，重新获得执行。一般说来，用户态驱动程序会单独创建一个线程专门用于等待中断；而后续中断处理由另外的线程来负责。

Peter给出了一些图标数据，主要是为了说明在用户态驱动程序框架下中断响应时间并没有明显增大。这种中断机制的主要问题在于很难支持共享型中断。

用户态驱动程序还面临另一个重大挑战DMA操作。为了支持DMA操作，需要新增加一些系统调用接口。这些接口还没有完全固定下来，但大致上就像下面的样子。在最初阶段，用户态驱动也需要打开一个专门的文件：

int usr_pci_open(int bus, int slot, int function);

然后建立DMA映射关系：

int usr_pci_map(int fd, int cmd, struct mapping_info *info);

上面的参数cmd可以是：

1）USR_ALLOC_CONSISTENT，建立固定的一致性映射关系。

2）USR_MAP，建立流映射关系或分散/聚集映射关系。

3）USR_UNMAP，在DMA完成撤销映射关系。

上的参数info用于相关参数描述【可能包括长度信息】，并获得返回的地址【可能包括用户虚地址和DMA总线地址】。

************************

很多对用户驱动程序的请求直接来用户空间其他应用程序，例如Xserver。也有很多对用户驱动程序的请求不是直接来自应用程序，因此需要在内核态挂一个钩子函数截获请求【对于这个需求来自内核协议层，例如块协议层、网络协议层。其实内核里面有很多协议层驱动完全可以放到用户态空间来实现，但是移植这些协议层软件也很有挑战】。

Many user-space drivers will be able to obtain their requests directly from user space; the X server works in this way. Many other drivers, however, will need to hook into the kernel for this information. The current patch includes a mechanism (Peter described it as ugly) for a user-space block driver to register itself with the kernel and get I/O requests. It works by opening another special file and using it to communicate requests and responses back and forth. A similar interface apparently exists for network drivers.

Getting a user-space driver patch into the kernel could be an interesting challenge. Many kernel hackers, certainly, resist changes that look like they are pushing Linux toward something that looks like a microkernel architecture - or which might legitimize binary-only drivers. On the other hand, some drivers bring a great deal of baggage into the kernel with them which might be better kept in user space; think of some of the code required by some sound drivers or the modulation software needed by "linmodem" drivers. The ability to run these drivers in user space could be a nice thing to have.