设备驱动可以运行在内核态，也可以运行在用户态，用户态驱动的利弊网上有很多的讨论，而且有些还上升到政治性上，这里不再多做讨论。不管用户态驱动还是内核态驱动，他们都有各自的缺点。内核态驱动的问题是：系统调用开销大；学习曲线陡峭；接口稳定性差；调试困难；bug致命；编程语言选择受限；而用户态驱动面临的挑战是：如何中断处理；如何DMA；如何管理设备的依赖关系；无法使用内核服务等。对此，《User-Space Device Drivers in Linux: A First Look》 一文有较详细描述。

可能是为了性能优化，或者为了故障隔离，或者为了逃避开源许可证的约束，不管是基于何种目的，linux已有多种用户态驱动的实现，如UIO，VFIO、USB用户态驱动等。它们在处理中断、DMA、设备依赖管理等方面的设计方案和实现细节上各有千秋，这是《User-Space Device Drivers in Linux: A First Look》 没有提到的，也是本文的重点。

UIO 框架导出sysfs和/dev/uioX 2套用户态接口，用户对设备节点/dev/uioX进行设备控制，mmap()接口用于映射设备寄存器空间，write()接口用于控制中断关闭/打开，read()接口用于等待一个设备中断。

因为对于设备中断的应答必须在内核空间进行，所以在内核空间有一小部分代码用来应答中断和禁止中断，其余的工作全部留给用户空间处理。如果用户空间要等待一个设备中断，它只需要简单的阻塞在对 /dev/uioX的read()操作上。 当设备产生中断时，read()操作立即返回。UIO 也实现了poll()系统调用，你可以使用 select()来等待中断的发生。select()有一个超时参数可以用来实现有限时间内等待中断。

UIO的几个特点：

总的来说，UIO框架适用于简单设备的驱动，因为它不支持DMA，不能支持多个中断线，缺乏逻辑设备抽象能力。

 上文提到，UIO不支持DMA，所以通过DMA传输大流量数据的IO设备，如网卡、显卡等设备，无法使用UIO框架，VFIO做为UIO的升级版，主要就是解决了这个问题。通过用户态配置IOMMU接口，可以将DMA地址空间映射限制在进程虚拟空间中。这对高性能驱动和虚拟化场景device passthrough尤其重要。

在VFIO框架中，有几个核心概念或对象：IOMMU、/dev/vfio、container、iommu_group。

VFIO的几个特点：

usbfs(USB file system)提供了一些在用户空间下操作USB设备的函数接口和数据结构, 在开发用户态驱动时, 可以直接利用这些函数接口来实现对 USB 设备的控制和数据传输。
libusb对usb file system提供的函数接口和数据结构进行了封装, 可以有效减少程序中函数和数据结构使用不当造成的错误。Libusb 对 USB 设备的访问提供了两种机制, 同步访问和异步访问。
khubd是内核后台线程，用来管理监视USB HUB的状态, 一旦发生热插拔就会唤醒这个线程, 进而添加或者移除设备，并发送netlink消息传递给用户态空间。

USB 用户态驱动框架的几个特点：

Linux Kernel v4.4

User-Space Device Drivers in Linux: A First Look

User-Mode Driver Framework

VFIO Introduction