编译包含非内核头文件的linux内核（2.6）模块
是否可以编译包含非内核包含定义的功能的 Linux 内核（2.6）模块？
例如：
kernelmodule.h
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h> // printk()
// ...
#include <openssl/sha.h>
// ...
Makefile
obj-m := kernelmodule.o
all:
$(MAKE) -C /lib/modules/`uname -r`/build M=`pwd` modules
clean:
$(MAKE) -C /lib/modules/`uname -r`/build M=`pwd` clean
$(RM) Module.markers modules.order
我编写并尝试编译的内核模块包含在许多 openssl 包含文件中找到的功能。
上面提供的标准 makefile 不允许包含 Linux 标头之外的内容。 是否可以包含此功能，如果可以，请您指出正确的方向。
谢谢， 麦克风
Is it possible to compile a linux kernel(2.6) module that includes functionality defined by non-kernel includes?
For example:
kernelmodule.h
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h> // printk()
// ...
#include <openssl/sha.h>
// ...
Makefile
obj-m := kernelmodule.o
all:
$(MAKE) -C /lib/modules/`uname -r`/build M=`pwd` modules
clean:
$(MAKE) -C /lib/modules/`uname -r`/build M=`pwd` clean
$(RM) Module.markers modules.order
The kernel module I have written and are trying to compile contains functionality found in a number of openssl include files.
The standard makefile presented above doesn't allow includes outside of the linux headers. Is it possible to include this functionality, and if so, could you please point me in the right direction.
Thanks,
Mike
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
内核不能使用用户空间代码并且必须独立（即完全自包含，没有库），因此它不获取标准头文件。
目前尚不清楚尝试获取用户空间标头有什么好处。 如果其中有一些可以有效使用的东西（常量，一些宏可能假设它们不调用任何用户空间函数），那么最好复制它们并仅包含您需要的内核兼容部分。
不可能将内核与专为用户空间使用而设计的库链接起来 - 即使它们不进行任何操作系统调用 - 因为内核中的链接环境无法获取它们。
相反，重新编译要在内核中使用的任何函数（假设它们不进行任何操作系统或库调用 - 例如 malloc - 在这种情况下无论如何都需要修改它们）。 将它们合并到您自己的库中，以便在您的内核模块中使用。
最新版本的 Linux 无论如何都包含加密函数，包括各种 SHA 哈希值 - 也许您可以使用其中之一。
另一个想法是停止尝试在内核空间中进行加密并将代码移至用户空间。 用户空间代码更容易编写/调试/维护等。
The kernel cannot use userspace code and must stand alone (i.e. be completely self contained, no libraries), therefore it does not pick up standard headers.
It is not clear what benefit trying to pick up userspace headers is. If there are things in there that it would be valid to use (constants, some macros perhaps provided they don't call any userspace functions), then it may be better to duplicate them and include only the kernel-compatible parts that you need.
It is not possible to link the kernel with libraries designed for userspace use - even if they don't make any OS calls - because the linking environment in the kernel cannot pick them up.
Instead, recompile any functions to be used in the kernel (assuming they don't make any OS or library calls - e.g. malloc - in which case they'll need to be modified anyway). Incorporate them into your own library to be used in your kernel modules.
Recent versions of linux contain cryptographic functions anyway, including various SHA hashes - perhaps you can use one of those instead.
Another idea would be to stop trying to do crypto in kernel-space and move the code to userspace. Userspace code is easier to write / debug / maintain etc.
我已经编写了一些用户空间代码并将其转换为在内核空间中工作（即使用 kmalloc() 等），这并不困难。 但是，您仅限于内核对 C 的理解，而不是用户空间，这略有不同......尤其是对于各种标准 int 类型。
仅仅链接到用户空间 DSO 是不可能的——Linux 内核是整体的、完全独立的。 正如其他人指出的那样，它不使用用户空间 libc、库或其他位。
9/10次，你会在内核的某个地方找到你需要的东西。 很可能其他人遇到了与您相同的需求，并在某个模块中编写了一些静态函数来执行您想要的操作..只需抓住这些函数并重新使用它们即可。
在加密的情况下，正如其他人所说，只需使用内核中的内容即可。 需要注意的一件事是，您需要在 kconfig 中启用它们，这可能会也可能不会发生，具体取决于用户在构建时选择的内容。 因此，请注意依赖关系并明确说明，您可能需要修改 kconfig 中的一些条目，以便在选择模块时也选择您想要的加密 API。 当用树构建时，这样做可能会有点痛苦。
因此，一方面我们“只是复制和重命名内容，同时增加整体膨胀”，另一方面你“告诉人们他们必须拥有完整的内核源代码”。 这是整体内核带来的怪癖之一。
使用微内核，几乎所有内容都在用户空间中运行，无需担心某些驱动程序与 DSO 的链接……这不是问题。 请不要将该声明视为在评论中重新启动内核设计理念的提示，这不属于本问题的范围。
I have taken bits of userspace code that I've written and converted it to work in kernel space (i.e. using kmalloc(), etc), it's not that difficult. However, you are confined to the kernel's understanding of C, not userspace, which differs slightly .. especially with various standard int types.
Just linking against user space DSO's is not possible — the Linux kernel is monolithic, completely self contained. It does not use userspace libc, libraries or other bits as others have noted.
9/10 times, you will find what you need somewhere in the kernel. It's very likely that someone else ran into the same need you have and wrote some static functions in some module to do what you want .. just grab those and re-use them.
In the case of crypto, as others have said, just use what's in the kernel. One thing to note, you'll need them to be enabled in kconfig which may or may not happen depending on what the user selects when building it. So, watch out for dependencies and be explicit, you may have to hack a few entries in kconfig that also select the crypto API you want when your module is selected. Doing that can be a bit of a pain when building out of tree.
So on the one hand we have "just copy and rename stuff while adding overall bloat", on the other you have "tell people they must have the full kernel source". It's one of the quirks that come with a monolithic kernel.
With a Microkernel, almost everything runs in userspace, no worries linking against a DSO for some driver ... it's a non issue. Please don't take that statement as a cue to re-start kernel design philosophy in comments, that's not in the scope of this question.