这个问题的核心在于内核模块的编译环境和用户空间程序完全不同——你在用户空间用gcc编译程序时依赖的是GNU C标准库（glibc），但内核模块是运行在内核态的，它有自己独立的头文件和函数集，根本无法访问用户空间的stdio.h这类头文件。你之前用gcc编译普通程序正常，是因为gcc默认使用用户空间的编译环境，和内核模块的编译链完全是两回事。

为什么会报错？ #

用户空间的stdio.h属于glibc的一部分，而内核模块的编译是通过内核自带的构建系统完成的，它不会链接任何用户空间的库，也找不到这些库的头文件。你的Makefile是标准的内核模块构建脚本，本身没有问题，问题出在代码里误用了用户空间的头文件。

正确的解决办法 #

你需要把代码中依赖用户空间标准库的部分，替换成内核提供的等价功能：

• 替换输出函数
  如果你用printf来打印信息，内核里对应的函数是printk，需要包含<linux/printk.h>头文件。比如：

  // 替换 #include <stdio.h>
  #include <linux/printk.h>
  
  // 替换 printf("xxx");
  printk(KERN_INFO "Your module message here\n");
  

  KERN_INFO是日志级别，内核还支持KERN_ERR、KERN_DEBUG等不同级别，你可以根据需求选择。

• 替换文件操作相关功能
  如果代码里用到了fopen、fread这类stdio的文件操作，你需要改用内核的文件访问接口，比如filp_open、vfs_read、vfs_write，这些函数定义在<linux/fs.h>里。注意内核态的文件操作需要遵循内核的权限规则，不能像用户空间那样随意访问文件。

• 字符串/内存操作
  如果用到了strcpy、memset这类函数，内核已经提供了对应的实现，你可以包含<linux/string.h>头文件，直接使用这些函数，不需要依赖用户空间的标准库。

绝对不要做的事 #

不要尝试修改Makefile来强制引入用户空间的头文件或库——这会导致模块无法加载，甚至直接崩溃，因为内核态和用户空间的内存空间、调用规范完全不兼容。

总结一下：内核模块不能使用用户空间的C标准库，必须改用内核原生的API和头文件。修改你的代码，替换掉所有依赖stdio.h的部分，就能解决编译报错的问题。

内容的提问来源于stack exchange，提问作者J.Meulenbeld