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

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

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

为了与SHT21传感器“对话”，我可以：

• 使用echo sht21 0x40>/sys/class/I2C适配器/I2C-0/new_设备实例化I2C设备，并通过

  hwmon

  访问湿度读数，解析输出，然后在我的应用程序中使用
• 编写我自己的软件，对

  /dev/i2c-0

  执行所需的

  write（）

  和

  read（）

  操作（根据数据表），自己计算湿度，然后在我的应用程序中使用

第一种方法使用

sht21

内核驱动程序，后者完全在用户空间中工作

---

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

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

如果有一个驱动程序可以解析和理解生产中使用的一些数据，那么如果它更容易使用或者拥有大量用户，就使用它。如果解析原始数据很简单，而且您的空间确实很紧张（我对此表示怀疑，因为您运行的是内核），那么就编写您自己的解析器，等等

简而言之，什么工作最简单（最不复杂），就这么做吧

在我的头顶上：

Userland方法的优点：

• 开发速度更快/调试更容易
• 如果buggy和崩溃，则无法使整个系统崩溃

用户土地方法的缺点：

• “表演”-我会留下一个非常模糊的概念 今天

对于您的应用程序，请从以下角度考虑：

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

…总而言之，我将200%支持用户土地方法。

---

内核空间在技术上可能更“有趣”或“有价值”，但工程技术将“务实”放在“有趣”之前

谢谢大家!！看来我会采用userland方法。顺便问一下：如果我在同一条总线上有多个传感器（当然有不同的I2C地址），并且由不同的并发应用程序访问，那么您知道内核是否负责处理互斥锁，以便只有一个应用程序可以同时获得I2C读/写锁，而让另一个应用程序处于I/O等待状态？这在实践中不会发生，因为董事会不会被设计成那样，但我还是很好奇。博士是，除此之外“核心源代码既是

真正的规范

又是

法律

，而实际审判是

真正该死的最终真相

。现在，我没有这方面的实际经验，但如果在这种情况下你不能得到干净的EBUSY/EAGAIN/ewoldblock，我会感到惊讶和失望……而且在任何情况下，一个快速编码的userland原型在最坏的情况下都是发现一些问题/限制/瓶颈的机会，而且在你的腰带下仍然有一个非一次性的小工具，充其量是迈向最终实施的第一步。