不能直接用C++编写Linux内核模块，必须用C实现；内核缺乏C++运行时支持，所有复杂逻辑应移交用户态C++程序协作处理。
不能直接用 C++ 编写 Linux 内核模块。
内核模块必须用 C 编写，且严格限制语言特性
Linux 内核本身是纯 C 实现，不提供 C++ 运行时（如 libstdc++）、异常处理、RTTI、构造/析构函数自动调用等机制。内核空间也不支持 new/delete、STL 容器、虚函数表或任何依赖 ABI 兼容的 C++ 特性。即使你用 g++ 强行编译出目标文件，加载时会因符号缺失（如 __cxa_begin_catch）或段错误立即失败。
- 内核构建系统（Kbuild）默认只调用
gcc，不识别.cpp后缀，也不会链接 C++ 标准库 - 所有内核头文件（如
<linux/module.h>）仅声明 C 链接接口，C++extern "C"包裹也救不了底层运行时缺失 - 极少数驱动曾尝试用 C++ 子集（禁用异常/RTTI/模板），但维护成本高、社区拒绝合入，2023 年后已无实际可行案例
真正可行的方案：用 C 实现 netfilter 钩子 + 用户态配合
Linux 防火墙功能基于 netfilter 框架，标准做法是在内核中注册 nf_hook_ops 结构体，挂载到协议栈关键点（如 NF_INET_PRE_ROUTING）。这必须用 C，但可与 C++ 用户态程序协作：
- 内核模块用 C 编写，只做轻量级匹配（如源 IP、端口、协议号），通过
skb->protocol、ip_hdr(skb)->saddr等原始字段判断，返回NF_DROP或NF_ACCEPT - 复杂规则解析（如正则、域名匹配、状态跟踪）移交用户态：内核模块用
netlink套接字（NETLINK_FIREWALL）与 C++ 程序通信，由后者下发规则到内核的哈希表或 BPF map - 若需高性能过滤，直接用 eBPF 替代手写模块：C++ 可通过
libbpf或bpftool加载 eBPF 程序，hook 点更安全、可热更新、无需模块签名
常见错误：误以为 “C++ 能调用 C 函数” 就能混用
即便你在模块里用 extern "C" 声明内核函数，以下问题仍无法绕过：
立即学习“C++免费学习笔记（深入）”；
-
printk()可用，但std::cout << "hello"会链接失败 —— 内核没有operator<<的实现 - 定义
std::vector<int> rules;编译不过：vector依赖malloc和异常传播，而内核只有kmalloc()且禁止抛异常 - 使用
std::string处理包头？不行 —— 内核中字符串操作只能用strnlen()、memcmp()等 C 函数，且必须确保内存已映射、无越界
真正要落地，得接受“内核侧 C + 用户侧 C++”的分层事实。最易踩的坑不是语法，而是把用户态开发习惯（比如动态分配、对象生命周期管理）直接套进内核上下文 —— 那里连 sleep 都可能引发调度错误。
