如果你可以从用户空间使用outbinb,那么Linux字符设备驱动程序有什么意义呢？

概述我很难理解何时应该编写设备驱动程序而不是仅仅通过我的用户空间程序中的outb将 *** 作码直接发送到硬件.我最初认为我应该为硬件创建简单的例程,但现在我开始认为算法应该保留在用户空间中. 假设我正在编程一个假想的机器人手臂.我可以在Linux内核模块中编写几个函数,这些函数可以自动执行常见任务所需的硬件输出(例如,将arm移动到HOME位置,从装配线开始处的已知位置拾取新块等).但是,在阅读了有关设备驱 我很难理解何时应该编写设备驱动程序而不是仅仅通过我的用户空间程序中的outb将 *** 作码直接发送到硬件.我最初认为我应该为硬件创建简单的例程,但现在我开始认为算法应该保留在用户空间中.

假设我正在编程一个假想的机器人手臂.我可以在Linux内核模块中编写几个函数,这些函数可以自动执行常见任务所需的硬件输出(例如,将arm移动到HOME位置,从装配线开始处的已知位置拾取新块等).但是,在阅读了有关设备驱动程序的更多信息之后,似乎经验法则是尽可能使设备驱动程序尽可能接近特定于硬件的代码,从而将“繁重的”算法留给用户空间.

这让我感到困惑,因为如果设备驱动程序实现的唯一函数是简单的 *** 作码调用,那么用户空间程序使用设备文件而不是直接调用outb / inb的原因是什么？

我想我想弄清楚的是：我如何决定内核空间而不是用户空间中的功能？

解决方法 好问题.我已经和那个人搏斗了 – 我甚至写过控制机器人手臂的司机,当我知道这个事实没有必要时.我可以通过串口或outb()等轻松发送命令.我只是为教育目的编写这些驱动程序.

设备驱动程序有很多很好的理由.想象一下,尝试直接从用户空间控制您的网卡！首先,驱动程序在 *** 作系统级别(eth0等)为您提供了一个很好的抽象.但是,从性能的角度来看,尝试处理用户空间中数据包发送/接收的中断将是非常不切实际的 – 甚至可能是不可能的.只需要在用户空间中响应中断所花费的时间就会将界面拖到膝盖上.

想象一下,你买了一张新的网卡.加载新驱动程序并继续从用户空间与eth0交谈而不更改代码不是很好吗？

所以,如果你没有看到需要,我会说“写一个驱动程序没有意义”.我认为驱动程序的存在是由需求驱动的(如在NIC驱动程序示例中),而不是相反.

听起来对你的应用来说,outb()比创建驱动程序要简单得多.最后,我甚至没有使用我的机器人手臂驱动程序 – 只需将字节写入串口工作就好了 – 只需要几行代码;-)

总结

以上是内存溢出为你收集整理的如果你可以从用户空间使用outb / inb,那么Linux字符设备驱动程序有什么意义呢？全部内容，希望文章能够帮你解决如果你可以从用户空间使用outb / inb,那么Linux字符设备驱动程序有什么意义呢？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。