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

Jor*_*räs 31 linux kernel module

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

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

我如何激励在(我相信)属于那里的用户空间中保存代码?

rpj*_*rpj 20

经验法则:尽你绝对最好的,让您的代码在用户空间.如果你认为不可能,那就花费尽可能多的时间研究内核代码的替代方案,就像编写代码一样(即:很长一段时间),然后再次尝试在用户空间中实现它.如果你仍然不能,研究更多,以确保你做出正确的选择,然后非常谨慎地进入内核.正如其他人所说,很少有情况决定编写内核模块和调试内核代码可能非常地狱,所以不惜一切代价明确.

至于在考虑编写内核模式代码时应该检查的具体条件,这里有几个:它是否需要访问极低级别的资源,例如中断?您的代码是否定义了无法在当前导出的功能之上构建的硬件的新接口/驱动程序?您的代码是否需要访问未从内核空间导出的数据结构或基元?您是在编写一些主要由其他内核子系统使用的东西,例如调度程序或VM系统(即使在这里,子系统并非完全必须是内核模式:Mach强烈支持用户模式虚拟内存寻呼机,所以它绝对可以做到)?


Mat*_*tW. 18

将内容放入内核的原因非常有限.如果您正在编写设备驱动程序,那就没关系.任何标准应用:永远不会.

缺点是巨大的.调试变得更难,错误变得更加频繁且难以找到.您可能会危及安全性和稳定性.您可能必须更频繁地适应内核更改.无法移植到其他UNIX操作系统.

我最接近内核的是一个自定义文件系统(后台有mysql),甚至为此我们使用了FUSE(U代表用户空间).


Sec*_*Sec 8

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

首先,调试变得更加困难,而且错误的影响要大得多(崩溃/恐慌而不是简单的coredump).


KOk*_*kon 5

基本上我同意rpj的观点。代码必须位于用户空间中,除非确实有必要。

但是,为了强调你的问题,哪个条件?

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

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

您应该移动到开销较大的内核空间,例如。用户-内核交换对于您的代码正常工作来说变得不可接受。

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

当人们谈论使用 RTOS 时,我通常持怀疑态度。如今,处理器的功能如此强大,以至于大多数时候,实时性变得可以忽略不计。

但是,即使您正在处理 SONET,并且您需要在 50ms 内进行保护切换(实际上甚至更短,因为 50ms 的限制适用于整个环),您仍然可以非常快地进行切换,如果您的硬件支持它。

如今,许多成帧器可以为您提供硬件支持,从而减少您需要执行的写入量。你的工作基本上就是尽快响应中断。Linux 一点也不差。即使我有大量其他中断正在运行(例如 IDE、以太网等),我得到的中断延迟也少于 1 毫秒。

如果这还不够,那么你的硬件设计可能是错误的。有些事情最好留在硬件上。当我说硬件时,我指的是 ASIC、FPGA、网络处理器或其他高级逻辑。