关于 kobject、kset 和 ktype 的所有你不想知道的事情¶
- 作者:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- 最后更新:
2007 年 12 月 19 日
基于 Jon Corbet 于 2003 年 10 月 1 日为 lwn.net 撰写的原始文章，位于 https://lwn.net/Articles/51437/
理解驱动模型（以及其所基于的 kobject 抽象）的困难之一在于，没有一个明显的切入点。处理 kobject 需要理解几种不同的类型，它们都相互引用。为了简化问题，我们将采用多遍方法，从模糊的术语开始，然后逐步添加细节。为此，这里对我们将要用到的一些术语进行快速定义。
kobject 是
struct kobject类型的一个对象。Kobject 具有名称和引用计数。Kobject 还具有一个父指针（允许对象排列成层次结构）、一个特定类型，并且通常在sysfs虚拟文件系统中有一个表示。Kobject 通常本身并不有趣；相反，它们通常嵌入在其他结构中，这些结构包含代码真正感兴趣的内容。
任何结构都绝不能嵌入一个以上的 kobject。如果嵌入了多个，对象的引用计数肯定会出错和不正确，您的代码将存在缺陷。所以不要这样做。
ktype 是嵌入 kobject 的对象类型。每个嵌入 kobject 的结构都需要一个相应的 ktype。ktype 控制 kobject 在创建和销毁时会发生什么。
kset 是一组 kobject。这些 kobject 可以是相同的 ktype，也可以属于不同的 ktype。kset 是 kobject 集合的基本容器类型。Kset 包含它们自己的 kobject，但您可以安全地忽略该实现细节，因为 kset 核心代码会自动处理此 kobject。
当您看到一个充满其他目录的
sysfs目录时，通常每个目录都对应于同一 kset 中的一个 kobject。
我们将了解如何创建和操作所有这些类型。我们将采用自下而上的方法，所以我们将回到 kobject。
嵌入 kobject¶
内核代码很少创建独立的 kobject，下面将解释一个主要例外。相反，kobject 用于控制对更大的、特定领域对象的访问。为此，kobject 将嵌入在其他结构中。如果您习惯于用面向对象的术语思考问题，kobject 可以被视为一个顶层抽象类，其他类由此派生。kobject 实现了一组本身并不特别有用，但在其他对象中却很好的功能。C 语言不允许直接表达继承，因此必须使用其他技术，例如结构体嵌入。
（顺便说一句，对于熟悉内核链表实现的人来说，这类似于“list_head”结构本身很少有用，但总是嵌入在更大型的对象中。）
因此，例如，drivers/uio/uio.c 中的 UIO 代码有一个结构体，用于定义与 uio 设备关联的内存区域。
struct uio_map {
struct kobject kobj;
struct uio_mem *mem;
};
如果您有一个 struct uio_map 结构体，查找其嵌入的 kobject 只需要使用 kobj 成员即可。然而，处理 kobject 的代码通常会遇到相反的问题：给定一个 struct kobject 指针，如何获取指向包含结构的指针？您必须避免技巧（例如假设 kobject 位于结构体的开头），而应使用在 <linux/kernel.h> 中找到的 container_of() 宏。
container_of(ptr, type, member)
其中
ptr是嵌入 kobject 的指针，
type是包含结构体的类型，并且
member是pointer指向的结构体字段的名称。
container_of() 的返回值是指向相应容器类型的指针。因此，例如，一个指向嵌入在 struct uio_map 内的 struct kobject 的指针 kp 可以通过以下方式转换为指向包含 uio_map 结构体的指针：
struct uio_map *u_map = container_of(kp, struct uio_map, kobj);
为了方便起见，程序员通常会定义一个简单的宏，用于将 kobject 指针反向转换为包含类型。在之前的 drivers/uio/uio.c 中正是如此，您可以在此处看到：
struct uio_map {
struct kobject kobj;
struct uio_mem *mem;
};
#define to_map(map) container_of(map, struct uio_map, kobj)
其中宏参数 “map” 是指向相关 struct kobject 的指针。该宏随后通过以下方式调用：
struct uio_map *map = to_map(kobj);
kobject 的初始化¶
创建 kobject 的代码当然必须初始化该对象。某些内部字段是通过（强制性的）调用 kobject_init() 来设置的。
void kobject_init(struct kobject *kobj, const struct kobj_type *ktype);
ktype 是正确创建 kobject 所必需的，因为每个 kobject 都必须有一个关联的 kobj_type。在调用 kobject_init() 之后，要向 sysfs 注册该 kobject，必须调用函数 kobject_add()。
int kobject_add(struct kobject *kobj, struct kobject *parent,
const char *fmt, ...);
这会正确设置 kobject 的父级和 kobject 的名称。如果 kobject 要与特定的 kset 关联，则必须在调用 kobject_add() 之前分配 kobj->kset。如果 kobject 与 kset 关联，则可以在调用 kobject_add() 时将 kobject 的父级设置为 NULL，然后 kobject 的父级将是 kset 本身。
由于 kobject 的名称是在将其添加到内核时设置的，因此 kobject 的名称绝不应直接操作。如果必须更改 kobject 的名称，请调用 kobject_rename()。
int kobject_rename(struct kobject *kobj, const char *new_name);
kobject_rename() 不执行任何锁定操作，也没有关于哪些名称有效的明确概念，因此调用者必须提供自己的健全性检查和序列化。
有一个名为 kobject_set_name() 的函数，但那是遗留的冗余代码，正在被移除。如果您的代码需要调用此函数，则它是错误的，需要修复。
要正确访问 kobject 的名称，请使用函数 kobject_name()。
const char *kobject_name(const struct kobject * kobj);
有一个辅助函数可以同时初始化 kobject 并将其添加到内核，令人惊讶的是它被称为 kobject_init_and_add()。
int kobject_init_and_add(struct kobject *kobj, const struct kobj_type *ktype,
struct kobject *parent, const char *fmt, ...);
参数与上面描述的单独的 kobject_init() 和 kobject_add() 函数相同。
Uevent 事件¶
kobject 注册到 kobject 核心后，您需要向外界宣布它已被创建。这可以通过调用 kobject_uevent() 来完成。
int kobject_uevent(struct kobject *kobj, enum kobject_action action);
当 kobject 首次添加到内核时，使用 KOBJ_ADD 操作。这应该仅在 kobject 的任何属性或子级已正确初始化之后进行，因为此调用发生时，用户空间会立即开始查找它们。
当 kobject 从内核中移除时（详细信息如下），KOBJ_REMOVE 的 uevent 将由 kobject 核心自动创建，因此调用者无需担心手动执行此操作。
引用计数¶
kobject 的关键功能之一是作为其嵌入对象的引用计数器。只要存在对对象的引用，对象（以及支持它的代码）就必须继续存在。用于操作 kobject 引用计数的底层函数是：
struct kobject *kobject_get(struct kobject *kobj);
void kobject_put(struct kobject *kobj);
成功调用 kobject_get() 会递增 kobject 的引用计数器并返回指向该 kobject 的指针。
当一个引用被释放时，调用 kobject_put() 将递减引用计数，并可能释放对象。请注意，kobject_init() 将引用计数设置为一，因此设置 kobject 的代码最终需要执行一次 kobject_put() 以释放该引用。
由于 kobject 是动态的，它们不能被声明为静态的或在栈上，而应始终动态分配。内核的未来版本将包含对静态创建的 kobject 的运行时检查，并将警告开发者这种不当用法。
如果您只想使用 kobject 为您的结构提供引用计数器，请改用 struct kref；使用 kobject 将会是多余的。有关如何使用 struct kref 的更多信息，请参阅 Linux 内核源代码树中的文件 为内核对象添加引用计数器 (krefs)。
创建“简单” kobject¶
有时，开发人员只是想在 sysfs 层次结构中创建一个简单的目录，而无需处理 kset、show 和 store 函数以及其他细节的复杂性。这是应该创建单个 kobject 的一个例外情况。要创建这样一个条目，请使用函数：
struct kobject *kobject_create_and_add(const char *name, struct kobject *parent);
此函数将创建一个 kobject，并将其放置在 sysfs 中指定父 kobject 下的位置。要创建与此 kobject 关联的简单属性，请使用：
int sysfs_create_file(struct kobject *kobj, const struct attribute *attr);
或
int sysfs_create_group(struct kobject *kobj, const struct attribute_group *grp);
这里使用的两种属性类型，对于通过 kobject_create_and_add() 创建的 kobject，都可以是 kobj_attribute 类型，因此无需创建特殊的自定义属性。
有关简单 kobject 和属性的实现，请参阅示例模块 samples/kobject/kobject-example.c。
ktype 和 release 方法¶
讨论中仍缺少一个重要事项，即当 kobject 的引用计数达到零时会发生什么。创建 kobject 的代码通常不知道何时会发生这种情况；如果知道，那么一开始使用 kobject 就没有什么意义了。当 sysfs 介入时，即使是可预测的对象生命周期也会变得更加复杂，因为内核的其他部分可以获取系统中注册的任何 kobject 的引用。
最终结果是，受 kobject 保护的结构在其引用计数归零之前不能被释放。引用计数不受创建 kobject 的代码的直接控制。因此，当其 kobject 的最后一个引用消失时，必须异步通知该代码。
一旦您通过 kobject_add() 注册了您的 kobject，就绝不能直接使用 kfree() 来释放它。唯一安全的方法是使用 kobject_put()。在调用 kobject_init() 之后始终使用 kobject_put() 是一个好习惯，以避免错误悄然出现。
此通知是通过 kobject 的 release() 方法完成的。通常此类方法的形式如下：
void my_object_release(struct kobject *kobj)
{
struct my_object *mine = container_of(kobj, struct my_object, kobj);
/* Perform any additional cleanup on this object, then... */
kfree(mine);
}
一个重要的点怎么强调都不为过：每个 kobject 都必须有一个 release() 方法，并且 kobject 必须持续存在（处于一致状态）直到该方法被调用。如果这些约束未满足，则代码存在缺陷。请注意，如果您忘记提供 release() 方法，内核会警告您。不要试图通过提供一个“空”的释放函数来消除此警告。
如果您所有的清理函数只需要调用 kfree()，那么您必须创建一个包装函数，该函数使用 container_of() 向上转换为正确的类型（如上例所示），然后对整个结构体调用 kfree()。
请注意，kobject 的名称在 release 函数中可用，但在此回调中绝不能更改它。否则，kobject 核心将出现内存泄漏，这将令人不悦。
有趣的是，release() 方法并非存储在 kobject 本身中；相反，它与 ktype 相关联。因此，让我们介绍一下 struct kobj_type：
struct kobj_type {
void (*release)(struct kobject *kobj);
const struct sysfs_ops *sysfs_ops;
const struct attribute_group **default_groups;
const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj);
const void *(*namespace)(struct kobject *kobj);
void (*get_ownership)(struct kobject *kobj, kuid_t *uid, kgid_t *gid);
};
此结构用于描述特定类型的 kobject（或更准确地说，是包含对象）。每个 kobject 都需要有一个关联的 kobj_type 结构；当您调用 kobject_init() 或 kobject_init_and_add() 时，必须指定指向该结构体的指针。
struct kobj_type 中的 release 字段当然是指向此类 kobject 的 release() 方法的指针。另外两个字段（sysfs_ops 和 default_groups）控制此类对象在 sysfs 中的表示方式；它们超出了本文档的范围。
default_groups 指针是一个默认属性列表，这些属性将为任何注册到此 ktype 的 kobject 自动创建。
kset¶
kset 仅仅是希望相互关联的 kobject 的集合。没有规定它们必须是相同的 ktype，但如果不是，请务必小心。
kset 具有以下功能：
它作为一个包含一组对象的“袋子”。内核可以使用 kset 来跟踪“所有块设备”或“所有 PCI 设备驱动程序”。
kset 也是
sysfs中的一个子目录，与 kset 关联的 kobject 可以在其中显示。每个 kset 都包含一个 kobject，该 kobject 可以设置为其他 kobject 的父级；sysfs层次结构的顶级目录就是以这种方式构建的。Kset 可以支持 kobject 的“热插拔”，并影响 uevent 事件如何报告给用户空间。
用面向对象的术语来说，“kset”是顶层容器类；kset 包含它们自己的 kobject，但该 kobject 由 kset 代码管理，不应由任何其他用户操作。
kset 将其子项保存在标准的内核链表中。Kobject 通过其 kset 字段指向其包含的 kset。在几乎所有情况下，属于 kset 的 kobject 都将其 kset（或严格来说，其嵌入的 kobject）作为其父级。
由于 kset 内部包含一个 kobject，因此它应该始终动态创建，而绝不能静态声明或在栈上声明。要创建一个新的 kset，请使用：
struct kset *kset_create_and_add(const char *name,
const struct kset_uevent_ops *uevent_ops,
struct kobject *parent_kobj);
当您使用完 kset 后，请调用：
void kset_unregister(struct kset *k);
来销毁它。这会将 kset 从 sysfs 中移除并递减其引用计数。当引用计数变为零时，kset 将被释放。由于可能仍然存在对 kset 的其他引用，因此释放可能在 kset_unregister() 返回之后发生。
在内核树中的 samples/kobject/kset-example.c 文件中可以看到使用 kset 的示例。
如果 kset 希望控制与其关联的 kobject 的 uevent 操作，它可以使用 struct kset_uevent_ops 来处理：
struct kset_uevent_ops {
int (* const filter)(struct kobject *kobj);
const char *(* const name)(struct kobject *kobj);
int (* const uevent)(struct kobject *kobj, struct kobj_uevent_env *env);
};
filter 函数允许 kset 阻止为特定 kobject 向用户空间发出 uevent。如果函数返回 0，则不会发出 uevent。
name 函数将被调用以覆盖 uevent 发送到用户空间的 kset 的默认名称。默认情况下，名称将与 kset 本身相同，但如果此函数存在，则可以覆盖该名称。
uevent 函数将在 uevent 即将发送到用户空间时被调用，以允许向 uevent 添加更多环境变量。
有人可能会问，既然没有介绍执行该功能的函数，kobject 是如何精确地添加到 kset 的。答案是此任务由 kobject_add() 处理。当 kobject 传递给 kobject_add() 时，其 kset 成员应指向 kobject 将所属的 kset。kobject_add() 将处理其余部分。
如果属于 kset 的 kobject 没有设置父 kobject，它将被添加到 kset 的目录中。并非 kset 的所有成员都必须存在于 kset 目录中。如果在添加 kobject 之前分配了一个显式的父 kobject，则 kobject 将注册到 kset，但添加在父 kobject 下。
kobject 移除¶
kobject 成功注册到 kobject 核心后，代码使用完毕时必须对其进行清理。为此，请调用 kobject_put()。通过这样做，kobject 核心将自动清理此 kobject 分配的所有内存。如果已为该对象发送了 KOBJ_ADD uevent，则将发送相应的 KOBJ_REMOVE uevent，并且将为调用者正确处理任何其他 sysfs 清理工作。
如果您需要对 kobject 进行两阶段删除（例如，当您需要销毁对象时不允许休眠），那么请调用 kobject_del()，它将从 sysfs 中注销 kobject。这使得 kobject “不可见”，但它并未被清理，并且对象的引用计数仍然相同。稍后调用 kobject_put() 以完成与 kobject 关联的内存清理。
如果构建了循环引用，可以使用 kobject_del() 来解除对父对象的引用。在某些情况下，父对象引用子对象是有效的。循环引用必须通过显式调用 kobject_del() 来解除，以便调用释放函数，并且先前循环中的对象相互释放。
可供复制的示例代码¶
要查看正确使用 kset 和 kobject 的更完整示例，请参阅示例程序 samples/kobject/{kobject-example.c,kset-example.c}，如果您选择了 CONFIG_SAMPLE_KOBJECT，它们将作为可加载模块构建。