当前位置:  开发笔记 > 后端 > 正文

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

如何解决《我应该什么时候编写Linux内核模块?》经验,为你挑选了3个好方法。

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

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

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



1> rpj..:

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

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



2> MattW...:

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

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

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



3> Sec..:

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

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

推荐阅读
李桂平2402851397
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有