嵌入式 Linux：内核驱动程序与用户空间驱动程序？答案

【问题标题】：Embedded Linux: kernel drivers vs user space drivers?嵌入式 Linux：内核驱动程序与用户空间驱动程序？
【发布时间】：2016-05-06 21:44:56
【问题描述】：

在 Linux 中选择使用内核空间或用户空间驱动程序时，是否有最佳方法（或至少有一些优点和缺点）？

例如，假设我正在开发一个基于 Sensirion SHT21 传感器的湿度感应板。我的应用程序将从传感器读取样本，然后以 JSON 形式呈现给 Web 应用程序使用。

为了与 SHT21 传感器“交谈”，我可以：

使用echo sht21 0x40 > /sys/class/i2c-adapter/i2c-0/new_device 实例化I2C 设备并通过hwmon 访问湿度读数，解析输出，然后在我的应用程序中使用它
编写我自己的软件来执行所需的（根据数据表）write() 和 read() 对 /dev/i2c-0 的操作并自己计算湿度，然后在我的应用程序中使用它

第一种方法使用sht21 内核驱动程序，后者完全在用户空间中工作。

我应该选择哪一个？我该如何选择？

【问题讨论】：

【解决方案1】：

我的头顶：

用户态方法专家：

用户态方法的缺点：

就您的应用程序而言，考虑到这一点：

因为我们可以放心地打赌，湿度不会发生显着变化时间短，
和/或您的传感器无论如何都有一些不可忽略的滞后（会它只是出于机械原因，例如一滴水落在它上面，它不会在一毫秒内消失），
...而且您可能不打算每次发送湿度测量值毫秒 - 你呢？
...即使您这样做了，大部分延迟（作为“与性能”）将来自将使其成为 JSON 的那部分，将其发送到服务器（显然都是用户空间的工作），并且 - 尽管这可能不关你的事，这仍然是用例的一部分 - 服务器的联网条件和处理时间，

...总而言之，我会 200% 采用用户态方法。

内核空间在技术上可能更“有趣”或“有益”，但工程将“实用”置于“有趣”之前。 :-)

【讨论】：

谢谢！看起来我会采用用户态方法。顺便说一句：如果我在同一总线上有多个传感器（当然具有不同的 I2C 地址）并由不同的并发应用程序访问，您是否知道内核是否负责处理互斥锁，以便只有一个应用程序可以获得 I2C 读取/write 同时锁定，而让另一个在 I/O 等待？这在实践中不会发生，因为电路板不会像那样设计，但我还是很好奇。
文档是here，除此之外“内核源代码是the real spec和the law，实际试用是the real damned final truth。现在，我没有这方面的实践经验，但如果在这种情况下你不能清理 EBUSY / EAGAIN / EWOULDBLOCK，我会感到惊讶和失望。
...无论如何，快速编码的用户空间原型在最坏的情况下有机会发现一些问题/限制/瓶颈，并且仍然获得非一次性随身携带的小工具，充其量只是迈向最终实施的第一步。

【解决方案2】：

在这两种情况下，您都在驱动从用户空间发生的事情，选项 2 意味着编写一个我会避免的驱动程序，如果它已经存在的话。

如果有一个驱动程序可以解析并理解生产中使用的某些数据，如果它更易于使用或拥有庞大的用户群，请使用它。如果解析原始数据很简单，而且你真的很挤空间（我怀疑这是因为你运行内核），那么编写你自己的解析器等。

简而言之，什么是最少的工作，即最不复杂的事情，那就去做吧。

【讨论】：