内核模块必须用C而非C++，因内核纯C实现、无C++运行时支持、链接和加载阶段均不兼容C++ ABI；若强行使用C++，将出现符号未定义、name mangling错误及Invalid module format等问题。
内核模块必须用C，不能用C++
Linux内核本身是纯C实现的，所有内核头文件、ABI、符号导出机制、链接脚本、编译约束（如禁用异常、RTTI、全局构造器）都只适配C语言。试图用g++编译.ko会直接失败：链接阶段找不到_Znwj（operator new）等符号，printk调用被name mangling破坏，module_init宏展开后无法匹配函数签名。
常见错误现象包括：
ERROR: modpost: "operator new(unsigned int)" [xxx.ko] undefined!WARNING: "__cxa_pure_virtual" [/path/xxx.ko] undefined!- 加载时
insmod报Invalid module format（因ELF节属性或重定位类型不兼容）
为什么C++的类、异常、STL都不能进内核模块
内核空间没有用户态的运行时支持：
- 没有
libstdc++或libc++，所有std::vector、std::string、std::shared_ptr都会链接失败 - 内核禁用浮点寄存器保存/恢复（
kernel_fpu_begin仅限极少数驱动显式启用），C++异常依赖栈展开和FPU状态，不可用 - 内核内存分配只能用
kmalloc/vmalloc，而new操作符默认绑定malloc——这在内核里根本不存在 - 所有C++全局对象的构造函数（如
static std::mutex m;）会在__initcall段执行，但内核不解析C++ init段，导致未定义行为
如果非要“模拟”C++风格，只能手动做三件事
这是权衡后的折中方案，不是真正用C++，而是用C写出接近C++的组织结构：
- 用
struct+ 函数指针模拟“类”：struct my_dev { int (*open)(struct my_dev *); void (*close)(struct my_dev *); }; - 用
container_of()宏替代this指针，避免裸指针传递 - 所有资源初始化/释放必须显式调用，比如
my_dev_init()和my_dev_exit()，绝不能依赖构造/析构 - 字符串处理只能用
strcpy/strlcpy/snprintf，禁用std::to_string等任何C++标准库函数
哪怕只在.c文件里写一行#include ，make modules也会在预处理阶段报错：找不到头文件。
Makefile里必须强制用gcc，且禁用C++特性
标准内核模块Makefile中这一行是铁律：
ccflags-y := -std=gnu89 -fno-exceptions -fno-rtti -fno-threadsafe-statics
其中关键点：
-
-std=gnu89：内核要求C89兼容（非C99/C11），禁用inline（用static inline代替）、restrict、变长数组等 -
-fno-exceptions和-fno-rtti防止编译器悄悄插入C++运行时代码 - 绝对不要写
CXX = g++或$(CXX)，所有源文件必须声明为obj-m += xxx.o，且xxx.c后缀不能改为.cpp
真正麻烦的不是语法，而是整个内核构建系统从Kbuild到modpost全程按C ABI校验——只要偏离一步，insmod就拒绝加载，且错误信息极其晦涩。别试图绕过它。
13万字C语言保姆级教程（深入）：立即使用
在学习笔记中，你将探索c语言的核心概念和高级技巧！
