编译linux内核(2.6)模块,包括非内核头

编译linux内核(2.6)模块,包括非内核头,linux,makefile,linux-kernel,static-libraries,kernel-module,Linux,Makefile,Linux Kernel,Static Libraries,Kernel Module,是否可以编译包含由非内核包含定义的功能的linux内核(2.6)模块 例如: 内核模块 #include <linux/init.h> #include <linux/module.h> #include <linux/kernel.h> // printk() // ... #include <openssl/sha.h> // ... 我编写并试图编译的内核模块包含许多openssl包含文件中的功能 上面介绍的标准makefile不允许

是否可以编译包含由非内核包含定义的功能的linux内核(2.6)模块

例如:


内核模块

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>   // printk()
// ...
#include <openssl/sha.h>
// ...
我编写并试图编译的内核模块包含许多openssl包含文件中的功能

上面介绍的标准makefile不允许包含linux头以外的内容。是否可以包含此功能,如果可以,请为我指出正确的方向

谢谢,
Mike

内核不能使用用户空间代码,必须独立运行(即完全自包含,没有库),因此它不会获取标准头

目前还不清楚获取用户空间头有什么好处。如果其中有一些东西是可以使用的(常量,一些宏,如果它们不调用任何用户空间函数的话),那么最好复制它们并只包含您需要的内核兼容部分

不可能将内核与为用户空间使用而设计的库相链接——即使它们不进行任何操作系统调用——因为内核中的链接环境无法获取它们

相反,重新编译要在内核中使用的任何函数(假设它们不进行任何操作系统或库调用-例如malloc-在这种情况下,它们无论如何都需要修改)。将它们合并到您自己的库中,以便在内核模块中使用


linux的最新版本包含加密函数,包括各种SHA哈希——也许您可以使用其中一种



另一个想法是停止尝试在内核空间进行加密,并将代码移动到用户空间。用户空间代码更容易编写/调试/维护等。

我将编写的用户空间代码转换成在内核空间中工作的代码(即使用kmalloc()等),这并不难。但是,您仅限于内核对C的理解,而不是用户空间,两者略有不同。。特别是各种标准int类型

仅仅针对用户空间DSO进行链接是不可能的——Linux内核是单片的,完全独立的。它不使用用户空间libc、库或其他位,正如其他人所指出的那样

9/10次,您将在内核的某个地方找到您需要的东西。很可能是其他人遇到了与您相同的需求,并在某个模块中编写了一些静态函数来满足您的需求。。只要抓住这些,然后再利用它们

在加密的情况下,正如其他人所说,只需使用内核中的内容。需要注意的一点是,您需要在kconfig中启用它们,这可能会发生,也可能不会发生,这取决于用户在构建时选择的内容。因此,要注意依赖关系,并且要明确,您可能需要在kconfig中破解一些条目,这些条目在选择模块时也会选择您想要的加密API。当在树上建筑时,这样做可能会有点痛苦

因此,一方面我们有“只需在添加总体膨胀的同时复制和重命名内容”,另一方面你有“告诉人们他们必须拥有完整的内核源代码”。这是单片内核的一个怪癖

有了微内核,几乎所有东西都在用户空间中运行,不用担心某些驱动程序会与DSO进行链接。。。这不是问题。请不要把这句话当作在评论中重新开始内核设计哲学的暗示,这不在这个问题的范围之内

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