我很难理解何时应该编写设备驱动程序，而不仅仅是通过outb我的用户空间程序将操作码直接发送到硬件。我最初认为我应该为硬件创建简单的例程，但现在我开始认为算法应该留在用户空间中。
假设我正在编写一个假设的机械臂。我可以在 Linux 内核模块中编写几个函数，这些函数可以自动执行常见任务所需的硬件输出（例如，将手臂移动到 HOME 位置，在装配线开始时从已知位置拾取新块等）。但是，在阅读了有关设备驱动程序的更多信息后，似乎经验法则是使设备驱动程序尽可能接近特定于硬件的代码，将“繁重”的算法留给用户空间。
这让我很困惑，因为如果设备驱动程序实现的唯一功能是简单的操作码调用，那么用户空间程序使用设备文件而不是直接调用outb/的原因是什么inb？
我想我想弄清楚的是：我如何决定内核空间而不是用户空间中的功能？
好问题。我已经为此苦苦挣扎——我什至编写了驱动程序来控制机械臂，当我知道事实上没有必要时。我可以通过串行端口或 outb() 等轻松发送命令。我编写这些驱动程序只是为了教育目的。
设备驱动程序有很多很好的理由。想象一下试图直接从用户空间控制你的网卡！首先，驱动程序在操作系统级别（eth0 等）为您提供了一个很好的抽象。但是从性能的角度来看，尝试处理用户空间中数据包发送/接收的中断是非常不切实际的——甚至可能是不可能的。仅仅响应用户空间中的中断所花费的时间就会将界面拖到膝盖上。
进一步想象你买了一张新的网卡。只加载新驱动程序并继续从用户空间与 eth0 对话而不更改代码不是很好吗？
因此，如果您没有看到需要，我会说编写驱动程序“没有意义”。我认为驱动程序的存在是由需求驱动的（如 NIC 驱动程序示例），而不是相反。
听起来对于您的应用程序，outb() 将比创建驱动程序更简单。最后，我什至没有使用我的机械臂驱动程序——只是将字节写入串行端口也能正常工作——并且只需要几行代码；-)
如果您在用户空间中使用outband inb，那么您的用户空间将是特定于 x86 的 - 用户空间outb()和inb()宏是使用 x86 程序集实现的。另一方面，如果您编写内核驱动程序，那么您的驱动程序将适用于任何支持 PCI 的架构 - 内核中的inb()和outb()功能以特定于架构的方式实现。内核还为您提供诸如request_region()确保您的 IO 端口不会与任何其他驱动程序冲突的功能。
此外，您的用户空间驱动程序需要以 root 身份运行（或者在技术上具有与CAP_SYS_RAWIOroot 等效的功能）。内核中的字符设备驱动程序意味着您可以使用字符设备文件的 UNIX 权限来控制哪个用户空间用户可以访问该设备。
设备驱动程序必须只实现处理硬件的机制（与操作系统无关）。解决方案的所有智能都必须存在于用户空间中。
是的，您可以在用户空间中做任何事情，但是：
它不可重复使用；其他用户空间程序必须重新实现访问机械臂的机制（例如）
表现不佳；这取决于应用程序，也许对于机械臂来说不是问题（很慢），但对于网卡、磁盘、显卡来说可能是问题
因此，对于机械臂，您应该在驱动程序中实现机制（移动电机，从传感器获取信息）。因此，您的程序和其他程序可以使用驱动程序通过 arm 做出一些聪明的事情。聪明的事情是由用户空间程序完成的：画 Gioconda，准备蛋糕，小心地移动炸药。驱动程序是基本功能的实现，以允许其用户使用硬件。
但显然，这取决于硬件和环境。