1. 从一次设备节点混乱说起：为什么需要 kset/kobj/ktype 这层抽象
很多人在接触 Linux 设备模型时，第一反应是"能注册设备、能出/sys节点就行了"，于是直接拿device_create或者更底层的kobject_create_and_add拼凑代码。我最早也是这么干的，结果在一个模拟项目里注册了十几个虚拟设备节点，跑起来之后发现/sys下的目录层级完全乱套：本该属于同一类的设备散落在不同父目录下，热插拔事件上报时找不到统一的归属，卸载模块时还得手动一个个清理，漏一个就留下悬空引用。那次排查花了我整整一个下午，最后才意识到问题不在"注册"这一步，而在于我压根没用对kset、kobject、ktype这三件套的分工。
这篇内容就是围绕这三个 API 展开的。kobject是设备模型里最基础的引用计数对象，kset是一组同类型kobject的集合容器，ktype则定义了某一类kobject的默认行为（释放、属性、uevent 等）。三者配合，构成了/sys目录树、设备分类、热插拔通知的底层骨架。适合谁看？如果你已经能写一个简单的字符设备驱动，但对/sys下那些目录是怎么长出来的、kset和kobject到底谁管谁、ktype的release为什么必须实现这些问题还犯迷糊，那这篇就是给你准备的。我会从实际代码结构出发，把三者的职责边界、注册流程、引用计数陷阱、以及我踩过的几个典型坑都摊开讲清楚。
需要先说明一点：内核版本差异比较大，kobject的初始化接口在早期是kobject_init配合手动赋值，后来演进出kobject_init_and_add这类封装，kset的创建也从静态定义转向kset_create_and_add动态创建。下面讲的内容以较新的动态创建方式为主线，遇到老接口会顺带提一句差异，你对照自己手上的内核版本取舍。
2. kobject：引用计数与 sysfs 入口的最小单元
2.1 kobject 到底承载了什么
把kobject理解成"一个能被/sys看见的对象的身份证 + 计数器"最贴切。它本身不关心你是设备、驱动还是总线，只负责三件事：维护引用计数（refcount_t）、挂到某个kset里形成层级、在/sys下对应一个目录项。源码里struct kobject的核心字段大致是这些：
struct kobject { const char *name; /* sysfs 目录名 */ struct list_head entry; /* 挂入所属 kset 的链表节点 */ struct kobject *parent; /* 父对象，决定 sysfs 层级 */ struct kset *kset; /* 所属集合 */ struct kobj_type *ktype; /* 行为描述 */ struct kernfs_node *sd; /* sysfs 目录项 */ refcount_t kref; /* 引用计数 */ /* ... 省略状态位等字段 */ };这里有个容易忽略的点：parent和kset是两个独立的概念。parent决定/sys里的目录嵌套关系，kset决定它属于哪个逻辑集合。大多数情况下两者一致（父对象就是 kset 内嵌的那个 kobject），但完全可以出现"父目录是 A，却属于集合 B"的情况。我见过有人把这两个混为一谈，结果kset的 uevent 广播发不到预期对象上。
引用计数的意义在于生命周期管理。kobject_get加一，kobject_put减一，减到零触发ktype->release回调做真正的内存释放。这个设计的好处是：只要还有人持有引用，对象就不会被提前销毁，避免了"用着用着内存没了"的经典悬空指针问题。
2.2 初始化与注册的标准姿势
动态创建一个 kobject 并挂到 sysfs，最常用的接口是：
int kobject_init_and_add(struct kobject *kobj, struct kobj_type *ktype, struct kobject *parent, const char *fmt, ...);参数含义很直白：kobj是你自己分配的结构体内嵌的那个 kobject，ktype指定行为，parent指定父目录（传NULL就挂到/sys根下），最后是变参格式化的目录名。调用成功后，/sys/<parent>/<name>目录就出现了。
这里必须强调一个顺序问题：先kobject_init_and_add，再暴露给外部使用。我踩过的坑是这样的——在初始化完成之前就把 kobject 指针存进了全局链表，另一个线程恰好此时遍历链表拿到它并调用kobject_get，而此时kref还没被正确初始化，计数从垃圾值开始加，后面kobject_put永远减不到零，对象泄漏。正确做法是初始化成功后再发布指针，发布动作本身要配合同步原语（比如加锁或者rcu_assign_pointer）。
对应的清理路径是kobject_put，不是kfree。很多人第一次写会直接kfree(kobj)，结果release回调没被调用，sysfs 目录项残留，后续同名注册直接失败。记住：kobject 的销毁权在引用计数手里，你只负责 put。
2.3 release 回调为什么不能省
kobj_type里的release是强制的，内核在kobject_put减到零时会调用它。如果你不实现，内核会打印警告并且对象内存永远不会被回收。这个回调里该做什么？释放你包裹 kobject 的那层结构体内存，以及清理你在初始化阶段申请的其他资源。
static void my_obj_release(struct kobject *kobj) { struct my_obj *obj = container_of(kobj, struct my_obj, kobj); kfree(obj); /* 释放外层结构体，kobject 是内嵌的 */ }container_of这个宏在这里是标配，因为 kobject 通常是内嵌在更大的结构体里的，release 拿到的是内嵌成员的指针，得反推回外层。这个模式在设备模型里到处都是，device、driver、bus_type全是这么组织的。
有个细节值得说：release 回调的执行上下文不保证是进程上下文，也不保证能睡眠，所以里面不要做可能阻塞的操作（比如拿 mutex、调kmalloc(GFP_KERNEL)）。我一般只做kfree这类轻量释放，复杂清理放到显式的销毁函数里，在 put 之前完成。
3. kset：把同类 kobject 收拢成一个集合
3.1 kset 与 kobject 的包含关系
kset本质上是"一组 kobject 的容器 + 一个内嵌的 kobject 作为集合自身的代表"。源码结构大致是：
struct kset { struct list_head list; /* 集合内所有 kobject 的链表 */ spinlock_t list_lock; struct kobject kobj; /* 集合自身的 kobject，对应 sysfs 目录 */ const struct kset_uevent_ops *uevent_ops; /* 热插拔事件策略 */ /* ... */ };注意kobj是内嵌的，这意味着每个 kset 在/sys下也有自己的目录。当你把一个 kobject 加进 kset（通过kobject_add时指定 parent 为 kset 的 kobj，或者直接设置kobj->kset），它会同时进入list链表，并在 sysfs 里成为 kset 目录的子项。
创建 kset 的现代接口是：
struct kset *kset_create_and_add(const char *name, const struct kset_uevent_ops *uevent_ops, struct kobject *parent_kobj);name是 sysfs 目录名，uevent_ops决定这个集合里的对象在热插拔时怎么上报，parent_kobj指定挂载位置。销毁用kset_unregister，它内部会对内嵌 kobject 做 put。
3.2 为什么用 kset 而不是自己维护链表
有人会问：我不就是想要个"同类对象列表"吗，自己搞个struct list_head加锁维护不行吗？行，但你得自己解决三件事：sysfs 目录的自动创建与层级、热插拔事件的统一上报、以及对象销毁时的自动摘链。kset 把这三件事都包了。
具体说，当 kobject 通过kobject_add挂到 kset 上时，内核自动把它加入list；kobject_del时自动摘除。你不需要在 release 里手动list_del，否则会二次删除导致链表损坏——这个坑我见过不止一次，表现是卸载模块时偶发 panic，堆栈指向__list_del_entry_valid。
热插拔这块，kset_uevent_ops提供三个回调：filter（决定某对象是否上报）、name（生成DEVTYPE之类的标识）、uevent（追加自定义环境变量）。如果你有一批虚拟设备需要用户态感知插拔，用 kset 统一管理比每个设备单独发 netlink 消息干净得多。
3.3 kset 的引用计数与生命周期
kset 内嵌的 kobject 也有引用计数，kset_get/kset_put是对它的封装。这里有个容易混淆的地方：kset 的引用计数和它内部成员的引用计数是独立的。一个 kobject 被加进 kset 时，并不会自动给 kset 加引用；反过来 kset 销毁时，也不会自动清理还在里面的成员（内核会打印警告说"kset 还有成员未移除"）。
所以正确的销毁顺序是：先把集合内所有 kobject 逐个kobject_del+kobject_put，确认list空了，再kset_unregister。我在一个模拟项目里图省事，直接kset_unregister了事，结果内核日志刷了一屏 "kobject: '%s' (%p): is not initialized, yet kobject_put() is being called"，虽然没立刻崩，但那些残留对象的 release 再也不会被触发，内存就这么漏了。
4. ktype：给一类 kobject 定义统一行为
4.1 ktype 与 kset 的职责区分
新手最容易把ktype和kset搞混，因为这俩名字都带"类型/集合"的意味。一句话区分：kset 管"谁和谁是一伙的"，ktype 管"这一伙对象长什么样、怎么死"。
struct kobj_type的核心字段：
struct kobj_type { void (*release)(struct kobject *kobj); /* 销毁回调，必填 */ const struct sysfs_ops *sysfs_ops; /* 属性读写方法 */ const struct attribute_group **default_groups; /* 默认属性组 */ /* ... */ };release前面讲过了。sysfs_ops配合default_groups决定这个 kobject 在 sysfs 下暴露哪些属性文件、读写时走哪个函数。比如你有一类传感器对象，每个都要暴露value和enable两个属性，就把属性定义放进default_groups，读写逻辑放进sysfs_ops，所有用这个 ktype 初始化的 kobject 自动获得这套属性，不用一个个手动sysfs_create_file。
这个"批量定义"的能力是 ktype 最大的价值。我早期写驱动时每个设备手动建属性文件，十几个设备就是十几份重复代码，改一个属性名要改十几处。后来统一到 ktype 的default_groups，属性定义只写一份，清爽太多。
4.2 一个 ktype 服务多个 kset 的典型场景
ktype 和 kset 不是一一绑定的。同一个 ktype 可以被不同 kset 里的 kobject 共用，只要这些对象的销毁逻辑和属性集合一致。举个实际的结构：假设你有一批"虚拟通道"对象，分成"输入通道"和"输出通道"两个 kset，但两类通道的释放逻辑、属性文件完全相同，那就定义一个 ktype，两个 kset 里的 kobject 初始化时都传这个 ktype。
反过来，同一个 kset 里的对象理论上也可以用不同 ktype，但这么做通常没意义，因为 kset 的语义就是"同类集合"。我建议保持"一个 kset 对应一个 ktype"的简单映射，除非有明确理由打破它，否则维护成本会上升。
4.3 default_groups 的属性定义实操
属性组的标准写法：
static ssize_t value_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf) { struct my_obj *obj = container_of(kobj, struct my_obj, kobj); return sysfs_emit(buf, "%d\n", obj->value); } static ssize_t value_store(struct kobject *kobj, struct kobj_attribute *attr, const char *buf, size_t count) { struct my_obj *obj = container_of(kobj, struct my_obj, kobj); int ret, val; ret = kstrtoint(buf, 0, &val); if (ret) return ret; obj->value = val; return count; } static struct kobj_attribute value_attr = __ATTR(value, 0644, value_show, value_store); static struct attribute *my_obj_attrs[] = { &value_attr.attr, NULL, }; ATTRIBUTE_GROUPS(my_obj); static struct kobj_type my_obj_ktype = { .release = my_obj_release, .sysfs_ops = &kobj_sysfs_ops, .default_groups = my_obj_groups, };ATTRIBUTE_GROUPS宏会自动生成my_obj_groups数组，省去手写attribute_group结构体的样板代码。sysfs_emit是较新内核推荐的输出函数，比sprintf安全（它会检查缓冲区边界）。kstrtoint比simple_strtol更严格，会拒绝非法输入，建议统一用它。
有个细节：__ATTR的权限位0644表示用户可读写、组和其他只读。如果你希望属性只读，用0444并且store传NULL。权限位写错不会导致编译错误，但运行时会发现写文件返回EACCES，排查时容易误以为是逻辑问题。
5. 三者协作的完整注册与销毁链路
5.1 从零搭一个最小可用的对象体系
把前面三块拼起来，一个完整的注册流程大致是这样（以动态创建为例）：
struct my_obj { struct kobject kobj; int value; }; static struct kset *my_kset; static int __init my_init(void) { struct my_obj *obj; int ret; /* 1. 创建 kset，挂到 /sys/kernel 下 */ my_kset = kset_create_and_add("my_objects", NULL, kernel_kobj); if (!my_kset) return -ENOMEM; /* 2. 分配并初始化一个成员对象 */ obj = kzalloc(sizeof(*obj), GFP_KERNEL); if (!obj) { ret = -ENOMEM; goto err_kset; } /* 3. 初始化 kobject，父对象设为 kset 的内嵌 kobj */ ret = kobject_init_and_add(&obj->kobj, &my_obj_ktype, &my_kset->kobj, "obj0"); if (ret) { kobject_put(&obj->kobj); /* 注意：失败也要 put */ goto err_kset; } return 0; err_kset: kset_unregister(my_kset); return ret; }这里有个非常关键的细节：kobject_init_and_add失败时，仍然需要调用kobject_put。因为kobject_init内部已经把引用计数初始化为 1，add 失败只是没挂上 sysfs，计数还在。不 put 就泄漏。这个行为很多人不知道，我第一次遇到时以为是内核 bug，翻了源码才明白设计如此。
销毁路径反过来：
static void __exit my_exit(void) { /* 假设 obj 指针保存在某处 */ kobject_put(&obj->kobj); /* 触发 release，释放 obj */ kset_unregister(my_kset); /* 销毁集合 */ }顺序不能反。先 put 成员，再 unregister 集合。如果先 unregister 集合，成员对象的parent指向的 kobject 已经没了，后续 put 时访问parent可能出问题。
5.2 引用计数在协作中的传递关系
把引用计数的流转画清楚，很多 bug 就自然消失了。我总结成一张表：
| 操作 | 对 kobject 计数的影响 | 对 kset 计数的影响 |
|---|---|---|
kobject_init_and_add成功 | +1（初始持有） | 无直接变化 |
kobject_get | +1 | 无 |
kobject_put | -1，减到 0 触发 release | 无 |
kset_create_and_add | 无 | +1（内嵌 kobj 初始持有） |
kset_get | 无 | +1 |
kset_unregister | 无 | -1，减到 0 触发 kset 释放 |
从表里能看出，kset 和成员 kobject 的计数是两条独立的线。这也是为什么销毁时必须两边都处理。我见过一种错误写法：以为kset_unregister会自动 put 所有成员，于是只调它，结果成员全部泄漏。内核不会替你做这件事，因为成员可能还被别处引用着，贸然清理会破坏引用语义。
5.3 常见注册失败点与排查顺序
注册链路出问题时，按这个顺序排查效率最高：
- 同名冲突：
/sys下已存在同名目录，kobject_add返回-EEXIST。检查是不是上次卸载没清理干净，或者两个模块用了同一个名字。 - ktype 为 NULL 或 release 未实现：内核会警告并拒绝。确认
kobj_type结构体里release字段非空。 - parent 已销毁：父 kobject 被提前 put 了，add 时访问悬空指针。检查父对象的生命周期是否覆盖子对象。
- 内存分配失败：
kzalloc返回 NULL，通常是上下文用错了 GFP 标志（在原子上下文用了GFP_KERNEL）。
我一般在这几个点各加一条pr_debug，出问题时看日志就能定位到具体哪一步。比盲目加 printk 高效得多。
6. 几个让我印象深刻的踩坑记录
6.1 在 release 里访问 kset 导致的 UAF
有一次我在release回调里想顺手把对象从某个自定义链表摘掉，而那个链表的头挂在 kset 的私有数据里。代码大概是这样：
static void my_release(struct kobject *kobj) { struct my_obj *obj = container_of(kobj, struct my_obj, kobj); struct my_kset_priv *priv = ...; /* 从 kset 取私有数据 */ list_del(&obj->node); /* 访问了 kset 相关结构 */ kfree(obj); }问题在于，如果 kset 已经被kset_unregister销毁，priv就是悬空指针，list_del直接踩到已释放内存。表现是偶发 panic，而且只在"先销毁 kset 再 put 成员"的错误顺序下触发，复现率不高，排查了很久。
修复方式是把链表操作从 release 里挪出来，放到显式的销毁函数里，在 put 之前完成。release 只做纯粹的kfree。这个教训让我形成了一个习惯：release 回调里只碰 kobject 自身和外层结构体，绝不访问任何可能先于它销毁的外部结构。
6.2 kset 名字里的斜杠引发的目录错乱
kset_create_and_add的name参数如果包含/，内核会把它当成路径分隔符，在 sysfs 里创建多级目录。我当初为了"分类清晰"，写了个"group/subgroup"这样的名字，结果目录是建出来了，但后续kobject_add时 parent 指向 kset 的 kobj，路径拼接出现意外嵌套，/sys下多出一层莫名其妙的目录。
sysfs 的目录名规则比想象中严格：不能含/，不能是.或..，长度也有限制。命名时用下划线或短横线代替分隔符，比如group_subgroup。这个规则对 kobject 的name同样适用。
6.3 属性文件读写时的并发问题
default_groups里的属性读写函数默认没有加锁，多个进程同时读写同一个属性会竞争。我早期的一个计数器属性就吃过亏：两个进程同时store，读-改-写不是原子的，最终值比预期少。修复很简单，在store里加个 mutex 或者用atomic_t：
static ssize_t value_store(...) { int val, ret = kstrtoint(buf, 0, &val); if (ret) return ret; mutex_lock(&obj->lock); obj->value = val; mutex_unlock(&obj->lock); return count; }注意 mutex 不能用在中断上下文，如果属性可能被中断路径访问，得换成 spinlock 或者atomic_set。这个选择取决于你的数据被谁访问，没有通用答案。
6.4 忘记处理 kobject_init_and_add 的失败返回值
这个坑最基础但最常见。kobject_init_and_add返回非零时，对象处于"已初始化但未挂载"的中间状态，必须 put 掉。我见过有人直接return ret，对象泄漏。更隐蔽的是，如果这个函数在循环里被调用多次，每次失败都漏一个，跑久了内存曲线缓慢上升，很难第一时间联想到是这里。
统一写法是：
ret = kobject_init_and_add(...); if (ret) { kobject_put(&obj->kobj); return ret; }把 put 和失败处理绑死，形成肌肉记忆。
7. 关于接口选型与版本差异的几点经验
7.1 什么时候用 kset，什么时候直接 kobject
不是所有场景都需要 kset。如果你只有一个孤立的 kobject，或者几个对象之间没有"同类集合"的语义，直接kobject_init_and_add挂到合适的 parent 下就行，不必为了用而用。kset 的价值在"批量管理 + 统一 uevent + 自动链表维护"，当你有三个以上同类对象、或者需要热插拔上报时，它才划算。
反过来，如果你发现自己在手动维护一个list_head来跟踪同类 kobject，那基本就是该上 kset 的信号了。自己维护链表意味着你要处理加锁、摘链、销毁顺序，这些 kset 都替你做了。
7.2 新旧接口的对照
不同内核版本接口差异集中在初始化和创建上，整理成表方便对照：
| 用途 | 较新接口 | 早期接口 |
|---|---|---|
| 创建 kset | kset_create_and_add | kset_create+kset_register |
| 初始化 kobject | kobject_init_and_add | kobject_init+kobject_add |
| 创建并添加 | kobject_create_and_add | 手动 alloc + init + add |
| 属性输出 | sysfs_emit | sprintf/scnprintf |
老接口并非不能用，只是步骤多、容易漏掉中间的错误处理。新接口把"初始化 + 添加"合并成一个原子操作，失败时语义更清晰。如果你维护的代码要兼容多个内核版本，可以用宏做条件编译，但更实际的做法是锁定目标内核版本，用对应版本的接口，避免为了兼容引入一堆#if。
7.3 调试设备模型的实用手段
排查 kset/kobject 问题时，我常用的几个手段：
- 看
/sys实际结构：find /sys/kernel/my_objects -type d确认目录层级是否符合预期。 - 看引用计数：
/sys/kobject/<name>下有uevent等文件，但计数不直接暴露，得靠内核日志里的kobject调试信息（需要开CONFIG_DEBUG_KOBJECT）。 - 开
CONFIG_DEBUG_KOBJECT_RELEASE：这个选项会让 release 延迟执行，专门用来暴露"release 之后还有人访问"的 UAF 问题，排查悬空引用时非常有用。 dmesg过滤：dmesg | grep -i kobject能看到内核关于 kobject 的所有警告，包括未初始化就 put、release 缺失等。
这些手段配合起来，大部分设备模型的问题都能定位。关键是要养成"注册完立刻看/sys确认结构"的习惯，别等到出问题再回头查。
8. 把三个 API 串成一条可复用的心智模型
写到这里，我想给这三个 API 一个统一的心智模型，方便你在实际编码时快速判断该用哪个。把设备模型想象成一栋办公楼：kobject是每个房间的门牌和钥匙（引用计数决定谁能进、什么时候拆），kset是楼层或部门（把同类房间归到一起，统一管理进出和广播），ktype是房型模板（决定这类房间配什么家具、怎么拆）。你建一个新房间，先选房型（ktype），再决定放哪层（kset 或 parent），最后挂牌（kobject_init_and_add）。拆房间时先交钥匙（put），再撤楼层（unregister）。
这个类比不完美，但足够帮你在写代码时快速定位职责。实际项目里，我建议把"创建 kset → 定义 ktype → 批量初始化成员"封装成一个模块级的 init 函数，销毁路径对称地封装成 exit 函数，中间的错误处理用goto链统一收口。这样即使成员数量变化，注册和销毁逻辑也不用改，维护成本最低。
最后分享一个我自己的检查清单，每次写完涉及这三个 API 的代码，提交前过一遍：release 是否只做轻量释放、kobject_init_and_add失败是否 put、kset 销毁前成员是否清空、属性读写是否考虑了并发、sysfs 名字是否含非法字符。这五条覆盖了我这些年踩过的绝大多数坑，希望对你有用。
