我应该什么时候编写Linux内核模块？

出于某种原因，有些人希望在Linux中将代码从用户空间移动到内核空间。很多时候，原因似乎是代码应该具有特别高的优先级，或者仅仅是“内核空间更快”

这对我来说似乎很奇怪。什么时候应该考虑编写内核模块？有一套标准吗

---

我怎样才能激励将代码保存在（我认为）属于那里的用户空间中？

我不确定这个问题是否正确。应该有一个很好的理由将东西移动到内核空间。如果没有任何理由，就不要这样做

---

一方面，调试变得更加困难，错误的影响要严重得多（崩溃/死机而不是简单的coredump）。

内核中运行的代码以不同于用户空间代码的方式访问内存、外围设备和系统功能，因此能够更高效地运行。更不用说减少了内核代码的安全限制。然而，所有这些通常都是有代价的，比如增加内核面临安全威胁的可能性、锁定操作系统、使调试复杂化等等。

将内容放入内核的理由非常有限。如果您正在编写设备驱动程序，那么就可以了。任何标准应用：从不

缺点是巨大的。调试变得越来越困难，错误变得越来越频繁，也越来越难以发现。你可能会危及安全和稳定。您可能需要更频繁地适应内核更改。无法移植到其他UNIX操作系统

---

我所见过的最接近内核的是一个自定义文件系统（后台是mysql），甚至为此我们使用了FUSE（U代表用户空间）。

作为一般规则。想想你想知道什么，如果这是你在操作系统开发书籍或类中看到的东西，那么它很有可能属于内核。如果没有，请将其放在内核之外。如果你有一个很好的理由去打破这条规则，那么你肯定会有足够的知识让你自己知道，或者你会和一个有这方面知识的人一起工作

---

是的，可能听起来很刺耳，但这正是我的意思，如果你不知道，那么几乎可以肯定答案是否定的，不要在内核中这样做。将开发转移到内核空间会打开一个巨大的蠕虫罐，您必须确保能够处理它。

经验法则：尽最大努力将代码保存在用户空间中。如果你认为你做不到的话，花尽可能多的时间研究内核代码的替代方案，就像你写代码一样（比如：很长一段时间），然后再次尝试在用户空间中实现它。如果您仍然不能，请进行更多的研究以确保您做出了正确的选择，然后非常谨慎地进入内核。正如其他人所说，很少有情况会要求编写内核模块，而调试内核代码可能会非常糟糕，因此要不惜一切代价避免

---

至于在考虑编写内核模式代码时应该检查的具体条件，这里有几个：它是否需要访问极低级别的资源，例如中断？您的代码是否为无法在当前导出功能之上构建的硬件定义了新接口/驱动程序？您的代码是否需要访问未导出到内核空间之外的数据结构或原语？您是否正在编写一些主要由其他内核子系统使用的东西，例如调度器或VM系统（即使在这里，子系统也不一定是内核模式：Mach对用户模式虚拟内存寻呼机有很强的支持，因此它肯定可以实现）？

如果您的员工想要真正的高优先级、确定性，低延迟等，正确的方法是使用一些实时版本的Linux（或其他操作系统）

---

另外，请查看可抢占内核选项等。您应该做什么取决于需求，但将代码放入内核模块可能不是正确的解决方案，除非您直接与某些硬件接口。

如果您只需要更低的延迟、更高的吞吐量等。，购买速度更快的计算机可能比开发内核代码更便宜

内核模块可能更快（由于更少的上下文切换、更少的系统调用开销和更少的中断），并且确实以非常高的优先级运行。如果您想将少量相当简单的代码导出到内核空间，这可能是可以的。也就是说，如果发现一小段代码对性能至关重要，并且是那种可以从置于内核模式中获益的代码，那么将其置于内核模式可能是合理的

---

但是应该避免将程序的大部分移动到内核空间，除非所有其他选项都已完全用尽。除了这样做的困难之外，性能方面的好处不大。

基本上，我同意rpj。除非确实需要，否则代码必须在用户空间中

但是，为了强调你的问题，哪种情况

有些人声称驱动程序必须在内核中，这是不正确的。有些司机对时间不敏感，事实上很多司机都是这样

例如，成帧器、RTC定时器、i2c设备等。这些驱动程序可以轻松地移动到用户空间。甚至有些文件系统是在用户空间中编写的

您应该转移到内核空间，在那里，开销（例如用户内核交换）对于代码正常工作来说是不可接受的

但是有很多方法可以解决这个问题。例如，/dev/mem提供了一种访问物理内存的好方法，就像从内核空间访问物理内存一样

当人们谈论去RTO时，我通常持怀疑态度。 如今，处理器功能强大，大多数时候，实时性变得微不足道

但即使是在处理SONET时，也需要在50ms内进行保护切换（实际上是