对于linux / unix专家来说,请帮助我了解设备驱动程序.据我所知,驱动程序是直接与硬件交互的代码,并且暴露了一些apis来访问设备.我的问题是这段代码在哪里运行,用户空间或内核空间？
我知道在内核空间中执行的代码有一些额外的权限,如访问任何内存位置(如果我错了,请务必正确).如果我们安装第三方驱动程序,如果它在内核空间运行,这对整个系统是不是有害的？操作系统如何处理？
第2部分：
让我们举个例子说明USB设备(摄像机,键盘..),系统如何识别这些设备？系统如何知道要安装哪个驱动程序？驱动程序如何知道设备的地址读取和写入数据？
(如果这太大了,不能回答这里,请提供一些良好的文档或教程的链接..我已经尝试,找不到这些的答案pls help)
解决方法
在Linux上,驱动程序在内核空间中运行.是的,正如你所说的那样,对此有重大的安全隐患.驱动程序中的大多数异常将占用内核,从而可能会损坏内核内存(带来各种后果). Buggy驱动程序也会对系统安全性产生影响,而恶意驱动程序可以做任何事情.
MacOSX和Window NT内核看到的趋势是用户空间驱动. Microsoft已经有一段时间推动了Windows Userspace Driver Framework,MacOSX长期以来为Firewire和USB驱动程序提供了用户空间API,并为许多USB外设提供了符合类别的驱动程序.在MacOSX上安装第三方内核模式设备驱动程序是非常不寻常的.
可以理解的是,Windows用于内核混乱的不良声誉可归因于与每个手机,相机和打印机相关的(通常质量差)的内核模式驱动程序.
Linux图形驱动程序几乎全部在用户空间中实现,内核驻留部分最少,Fuse允许在用户空间中实现归档系统.
第2部分
USB,Firewire,MCI(以及PCI-e)均具有枚举机制,通过该机制,总线驱动程序可以将该设备与驱动程序相匹配.实际上,这意味着所有设备都会公开描述它们的元数据.
元数据中包含的是DeviceID,VendorID以及设备提供的功能描述和相关的ClassID. ClassID便于通用Class Drivers.
在概念上,操作系统将尝试找到一个特别支持VendorID和DeviceID的驱动程序,然后回到支持ClassID的驱动程序.
匹配设备与驱动程序是Linux Device Model核心概念,匹配的精确匹配标准是特定总线驱动程序中的match()函数.
一旦设备驱动程序被绑定到一个设备,它使用总线驱动程序(或由它提供的寻址信息)执行读写操作.在PCI和Firewire的情况下,这是一个内存映射的IO地址.对于USB,它的总线寻址信息.
Linux Documentation tree提供了对Linux设备模型设计的一些了解,但并不是真正的入门级阅读.
