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

Question

第1部分:

对于那里的linux/unix专家,请你帮我理解设备驱动程序.据我所知,驱动程序是一段代码,它直接与硬件交互并暴露一些api来访问设备.我的问题是这段代码在哪里运行,用户空间或内核空间？

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

第2部分:

让我们举一个USB设备(相机,键盘......)的例子,系统如何识别这些设备？系统如何知道要安装哪个驱动程序？驱动程序如何知道设备的地址以读取和写入数据？

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

Answer 1

第1部分

在Linux上,驱动程序在内核空间中运行.是的,正如你所说,对此存在重大的安全隐患.驱动程序中的大多数异常都会占用内核,可能会损坏内核内存(带来各种后果).Buggy驱动程序也会对系统安全性产生影响,恶意驱动程序可以完全执行他们想要的任何操作.

在MacOSX和Window NT内核上看到的趋势是用户空间驱动程序.微软一直在推动Windows用户空间驱动程序框架,MacOSX长期以来为Firewire和USB驱动程序提供了用户空间API,并为许多USB外围设备提供了类兼容的驱动程序.在MacOSX上安装第三方内核模式设备驱动程序是很不寻常的.

可以说,Windows过去对内核恐慌造成的不良声誉可归因于几乎所有移动电话,相机和打印机附带的(通常质量较差的)内核模式驱动程序.

Linux图形驱动程序几乎全部在用户空间中实现,具有最小的内核驻留部分,而Fuse允许在用户空间中实现文件系统.

第2部分

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

元数据中包含DeviceID,VendorID以及设备提供的功能描述和相关的ClassID.ClassID有助于通用类驱动程序.

从概念上讲,操作系统将尝试查找专门支持VendorID和DeviceID的驱动程序,然后回退到支持ClassID的驱动程序.

将设备匹配到驱动程序是Linux设备模型核心的核心概念,用于匹配的精确匹配标准是match()特定总线驱动程序中的功能.

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

在Linux文档树提供了一些见识到了Linux的设备模型的设计,但不是真正的入门级读数.

我还建议阅读Linux设备驱动程序(第3版)