设备驱动程序代码在哪里执行？内核空间还是用户空间？答案

【问题标题】：where is device driver code executed? Kernel space or User space?设备驱动程序代码在哪里执行？内核空间还是用户空间？
【发布时间】：2012-11-03 18:39:39
【问题描述】：

第 1 部分：

致 linux/unix 专家，请您帮助我了解设备驱动程序。据我了解，驱动程序是一段代码，它直接与硬件交互并公开一些 api 来访问设备。我的问题是这段代码在哪里运行，用户空间还是内核空间？

我知道在内核空间中执行的代码有一些额外的权限，比如访问任何内存位置（如果我错了，请纠正）。如果我们安装一个第三方驱动，如果它在内核空间运行，这对整个系统不会有害吗？任何操作系统如何处理这个问题？

第 2 部分：

让我们以 USB 设备（相机、键盘..）为例，系统如何识别这些设备？系统如何知道要安装哪个驱动程序？驱动如何知道读写数据的设备地址？

（如果这里太大而无法回答，请提供一些好的文档或教程的链接..，我已经尝试过但无法找到这些答案。请帮助）

【问题讨论】：

你应该把这个问题分成两个独立的问题。
在我过去开发 Linux 设备驱动程序的日子里，设备驱动程序在内核中编译并执行 100% 的内核空间。如今，内核似乎保护自己免受有缺陷的设备驱动程序甚至中断它们。但如果是关于学术考试的问题，我会以“内核空间”作为答案。
关于USB设备检测，VID和PID用于识别设备。
感谢 cmets。这不是学术考试问题..:)。我只是想了解这是如何工作的。如果可能的话，请您详细说明您的答案并提供一些链接。

标签： linux-kernel operating-system device-driver

【解决方案1】：

第 1 部分

在 linux 上，驱动程序在内核空间中运行。是的，正如您所说，这对安全有重大影响。驱动程序中的大多数异常都会关闭内核，可能会损坏内核内存（带来各种后果）。有缺陷的驱动程序也会对系统安全产生影响，恶意驱动程序绝对可以为所欲为。

MacOSX 和 Window NT 内核上的一个趋势是用户空间驱动程序。一段时间以来，Microsoft 一直在推动Windows Userspace Driver Framework，MacOSX 长期以来一直为 Firewire 和 USB 驱动程序提供用户空间 API，并为许多 USB 外围设备提供类兼容驱动程序。在 MacOSX 上安装 3rd 方内核模式设备驱动程序是很不寻常的。

可以说，Windows 过去因内核恐慌而声名狼藉的原因可归咎于几乎所有手机、相机和打印机都附带的（通常质量较差的）内核模式驱动程序。

Linux 图形驱动程序几乎都在用户空间中实现，内核驻留部分最少，Fuse 允许在用户空间中实现文件系统。

第 2 部分

USB、Firewire、MCI（以及 PCI-e）都具有枚举机制，总线驱动程序可以通过这些机制将设备与驱动程序匹配。实际上，这意味着所有设备都会公开描述它们的元数据。

元数据中包含 DeviceID、VendorID 以及设备提供的功能和相关 ClassID 的描述。 ClassID 有助于泛型 Class Drivers。

从概念上讲，操作系统将尝试找到专门支持 VendorID 和 DeviceID 的驱动程序，然后回退到支持 ClassID(s) 的驱动程序。

将设备与驱动程序匹配是Linux Device Model 的核心概念，用于匹配的精确匹配标准是特定总线驱动程序中的match() 函数。

一旦设备驱动程序绑定到设备上，它就会使用总线驱动程序（或由它提供的寻址信息）来执行读写操作。对于 PCI 和 Firewire，这是一个内存映射的 IO 地址。对于 USB it 总线寻址信息。

Linux Documentation tree 提供了对 Linux 设备模型设计的一些见解，但并不是真正的入门级阅读。

我也推荐阅读Linux Device Driver (3rd Edition)

【讨论】：