Vil*_*ray 3 c linux driver linux-device-driver linux-kernel
我很难理解何时应该编写设备驱动程序,而不是仅仅通过outb我的用户空间程序将操作码直接发送到硬件.我最初认为我应该为硬件创建简单的例程,但现在我开始认为算法应该保留在用户空间中.
假设我正在编程一个假想的机器人手臂.我可以在Linux内核模块中编写几个函数,这些函数可以自动执行常见任务所需的硬件输出(例如,将arm移动到HOME位置,从装配线开始处的已知位置拾取新块等).但是,在阅读了有关设备驱动程序的更多信息之后,似乎经验法则是尽可能使设备驱动程序尽可能接近特定于硬件的代码,从而将"繁重的"算法留给用户空间.
这让我感到困惑,因为如果设备驱动程序实现的唯一函数是简单的操作码调用,那么用户空间程序使用设备文件而不是直接调用outb/ 的原因是什么inb？
我想我想弄清楚的是:我如何决定内核空间而不是用户空间中的功能？
好问题.我已经和那个人搏斗了 - 我甚至写过控制机器人手臂的司机,当我知道这个事实没有必要时.我可以通过串口或outb()等轻松发送命令.我只是为教育目的编写这些驱动程序.
设备驱动程序有很多很好的理由.想象一下,尝试直接从用户空间控制您的网卡!首先,驱动程序在操作系统级别(eth0等)为您提供了一个很好的抽象.但是,从性能的角度来看,尝试处理用户空间中数据包发送/接收的中断将是非常不切实际的 - 甚至可能是不可能的.只需要在用户空间中响应中断所花费的时间就会将界面拖到膝盖上.
想象一下,你买了一张新的网卡.加载新驱动程序并继续从用户空间与eth0交谈而不更改代码不是很好吗？
所以,如果你没有看到需要,我会说"写一个驱动程序没有意义".我认为驱动程序的存在是由需求驱动的(如在NIC驱动程序示例中),而不是相反.
听起来对你的应用来说,outb()比创建驱动程序要简单得多.最后,我甚至没有使用我的机器人手臂驱动程序 - 只需将字节写入串口也能正常工作 - 并且只需要几行代码;-)
如果在用户空间中使用outb和inb,则用户空间将特定于x86 - 用户空间outb()和inb()宏通过x86程序集实现.另一方面,如果编写内核驱动程序而不是驱动程序可以在任何支持PCI的架构上运行 - 内核中的函数inb()和outb()函数都是以特定于体系结构的方式实现的.内核还为您提供request_region()了确保IO端口不与任何其他驱动程序冲突的功能.
此外,您的用户空间驱动程序需要以root身份运行(或者在技术上具有与CAP_SYS_RAWIOroot等效的功能).内核中的字符设备驱动程序意味着您可以使用字符设备文件上的UNIX权限来控制哪些用户空间用户可以访问该设备.