内核设备驱动程序或用户空间程序

Question

我目前使用运行 Linux 3.10.0+ 的 SAMA5D31-EK 板来控制一些硬件设备。我正在使用该板上提供的 GPIO、I2C、PWM 和 UARTS。有些设备仅使用 GPIO 线进行控制，而其他设备则需要 UART、PWM 和 3 个 GPIO。到目前为止，我正在使用用户空间程序来控制这些硬件设备 - 基本上是步进电机、ADC 和字母数字 LCD 显示屏。

开发内核设备驱动程序来控制这些设备有什么好处？到目前为止（使用用户空间程序）我发现的唯一限制是速度：因为我必须对一些 GPIO 进行位操作，所以结果有点慢。

Answer 1

我假设您的板上有可用于 I2C/GPIO/PWM/UART 接口的特定于平台的驱动程序（它应该是 BSP[Board-support-package] 的一部分）。

只是你不想使用内核设备驱动框架而想从用户空间做事情。我曾经遇到过这种情况，因此我知道它有多么诱人，特别是如果您不熟悉内核设备驱动程序。

a. SPEED：你提到过。但是，你可能没有完全理解其中的原因。

速度效率来自于避免内核和用户空间进程之间的上下文切换。这是一个例子：

/* A loop in kernel code which reads a register 100 time */
for (i = 0 ; i < 100 ; i++ )
{
  __kernel_read_reg(...);
}

/* A loop in User-space code which reads a register 100 time */
for ( i= 0 ; i < 100; i++)
{
   __user_read_reg(...);
}

从功能上看，两个 *_read_reg() 是相同的。假设 __user_read_reg() 将经历典型的系统调用过程，它必须为每个 __user_read_reg(...) 进行上下文切换，这成本太高了。

您可能会说，“我们可以 mmap() 硬件寄存器并避免此类操作的系统调用”。 当然，你可以这样做，但我想说的是： 接近硬件的操作（例如：寄存器读取或写入或处理中断）应尽可能快地完成。上下文切换涉及的延迟会影响性能。

b. 现有/经过测试/构建良好的子系统：

如果您在 Linux 内核中看到 I2C 子系统，它提供了一个经过充分测试的、健壮的框架，可以轻松重用。您不必在用户空间中编写完整的 I2C 子系统（处理所有设备类型、速度、各种配置等）。 在使用内核设备驱动程序时，重用”已经完成的内容可能是一大优势。

c. 从基于轮询的方法转向基于中断的机制

如果您不在内核驱动程序中处理中断，则必须在用户空间进程中使用某种轮询机制。根据系统的不同，它可能不是处理硬件更改的非常可靠的方式。对于快速设备来说绝对不准确/可靠。

基于中断的机制，一般来说，您可以尽快处理关键更改（硬件中断上下文）并将非关键工作负载移动到用户空间或其他内核机制，这是处理设备的更可靠的方式.

当然，除了以上三个之外，还可以有更多的论证和反驳。

您可能感兴趣的另一个主题在这里： 用户空间与内核空间驱动程序

Answer 2

内核中提供通用的用户空间驱动子系统： 用户空间 IO 司机.

控制设备的逻辑不一定必须位于内核内，因为设备不需要利用内核提供的任何其他资源。

因此，用户空间驱动程序是简单的驱动程序，仅支持对设备寄存器的内存访问和服务中断。

你说你正在使用用户空间程序来控制UART、GPIO、I2C、PWM？

内核中已经有这些子系统的内核驱动程序，所以可能是 您的用户空间程序已经在使用这些子系统的内核驱动程序。