设备驱动模型之sysfs与kobject
1. kobject, kset和ktype
要分析sysfs，首先就要分析kobject和kset，因为驱动设备的层次结构的构成就是由这两个东东来完成的。
sysfs与kobject密不可分。
1.1 kobject
kobject是组成设备模型的基本结构，是所有用来描述设备模型的数据结构的基类。
kobject是一个对象的抽象，它用于管理对象。
kobject被用来控制访问一个更大的，具有特定作用域的对象；为了达到这个作用，kobject将会被嵌入到其他结构体中。
如果你用面向对象的角度来看，kobject结构可以被看做顶层的抽象类，其他类都是从这个类派生出来的。
在sysfs中，每个kobject对应着一个目录。
/*include/linux/kobject.h*/
struct kobject {
/* 对应sysfs的目录名 */
const char *name;
/*用于连接到所属kset的链表中，用于将kobj挂在kset->list中*/
struct list_head entry;
/*指向 父对象，形成层次结构，在sysfs中表现为父子目录的关系*/
struct kobject *parent;
/*
属于哪个kset
表征该kobj所属的kset。
kset可以作为parent的“候补”：当注册时，传入的parent为空时，可以让kset来担当。
*/
struct kset *kset;
/*类型属性，每个kobj或其嵌入的结构对象应该都对应一个kobj_type。 */
const struct kobj_type *ktype;
/*sysfs中与该对象对应的文件节点对象*/
// 在3.14以后的内核中，sysfs基于kernfs来实现。
struct kernfs_node *sd; /* sysfs directory entry */
/*对象的应用计数*/
struct kref kref;
#ifdef CONFIG_DEBUG_KOBJECT_RELEASE
struct delayed_work release;
#endif
/* 记录初始化与否。调用kobject_init()后，会置位。 */
unsigned int state_initialized:1;
/* 记录kobj是否注册到sysfs，在kobject_add_internal()中置位。 */
unsigned int state_in_sysfs:1;
/* 当发送KOBJ_ADD消息时，置位。提示已经向用户空间发送ADD消息。*/
unsigned int state_add_uevent_sent:1;
/* 当发送KOBJ_REMOVE消息时，置位。提示已经向用户空间发送REMOVE消息。*/
unsigned int state_remove_uevent_sent:1;
/* 如果该字段为1，则表示忽略所有上报的uevent事件。 */
unsigned int uevent_suppress:1;
};
/*include/linux/kref.h*/
struct kref {
refcount_t refcount;
};
目前为止，Kobject主要提供如下功能：
- 构成层次结构：通过
parent指针，可以将所有Kobject以层次结构的形式组合起来。 - 生命周期管理：使用引用计数（
reference count），来记录Kobject被引用的次数，并在引用次数变为0时把它释放。 - 和
sysfs虚拟文件系统配合，将每一个Kobject及其特性，以文件的形式，开放到用户空间。
没有一个结构会嵌入多于一个kobject结构，如果这么做了，关于这个对象的引用计数肯定会一团糟，你的code也会充满bug，所以千万不要这么做。
实际上，kobject对自身实现什么功能并不感兴趣，它存在的意义在于把高级的对象链接到设备模型上。因此内核代码很少去创建一个单独的kobject对象，相反，kobject用于控制对大型域相关对象的访问（通过container_of）。
1.2 ktype
每个kobject对象都内嵌有一个ktype，该结构定义了kobject在创建和删除时所采取的行为，可以理解为对象的属性。
实际上，Kobject的生命周期管理就是由关联的ktype来实现的。
注意，每个kobject必须关联一个ktype。
由于通用性，多个Kobject可能共用同一个属性操作集，因此把Ktype独立出来了。
/*include/linux/kobject.h*/
struct kobj_type {
/* 处理对象终结的回调函数。该接口应该由具体对象负责填充。 */
void (*release)(struct kobject *kobj);
/* 该类型kobj的sysfs操作接口。 */
const struct sysfs_ops *sysfs_ops;
/* 该类型kobj自带的缺省属性（文件），这些属性文件在注册kobj时，直接pop为该目录下的文件。 */
const struct attribute_group **default_groups;
const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj);
/*child_ns_type/namespace 是 文件系统命名空间相关）略*/
const void *(*namespace)(struct kobject *kobj);
void (*get_ownership)(struct kobject *kobj, kuid_t *uid, kgid_t *gid);
};
/*include/linux/sysfs.h*/
struct sysfs_ops {
ssize_t (*show)(struct kobject *, struct attribute *, char *);
ssize_t (*store)(struct kobject *, struct attribute *, const char *, size_t);
};
struct attribute {
const char *name;
umode_t mode;
#ifdef CONFIG_DEBUG_LOCK_ALLOC
bool ignore_lockdep:1;
struct lock_class_key *key;
struct lock_class_key skey;
#endif
};
当kobject的引用计数为0时，通过release方法来释放相关的资源。
attribute为属性，每个属性在sysfs中都有对应的属性文件。
sysfs_op的两个方法用于实现读取和写入属性文件时应该采取的行为。
1.3 kset
kset是一些kobject的集合，这些kobject可以有相同的ktype（属性），也可以不同。
同时，kset自己也包含一个kobject；因此在sysfs中，kset也是对应这一个目录，但是目录下面包含着其他的kojbect。
也有一种说法，把Kset看是一个特殊的Kobject。
每个Kobject不一定出现在sys中，但Kset中的每个Kobject会出现在sys中。
/*include/linux/kobject.h*/
/**
* struct kset - a set of kobjects of a specific type, belonging to a specific subsystem.
*
* A kset defines a group of kobjects. They can be individually
* different "types" but overall these kobjects all want to be grouped
* together and operated on in the same manner. ksets are used to
* define the attribute callbacks and other common events that happen to
* a kobject.
*
* @list: the list of all kobjects for this kset
* @list_lock: a lock for iterating over the kobjects
* @kobj: the embedded kobject for this kset (recursion, isn't it fun...)
* @uevent_ops: the set of uevent operations for this kset. These are
* called whenever a kobject has something happen to it so that the kset
* can add new environment variables, or filter out the uevents if so
* desired.
*/
struct kset {
/*属于该kset的kobject链表，与kobj->entry对应，用来组织本kset管理的kobj*/
struct list_head list;
spinlock_t list_lock;
/*该kset内嵌的kobj*/
struct kobject kobj;
/*
kset用于发送消息的操作函数集。
需要指出的是，kset能够发送它所包含的各种子kobj、孙kobj的消息；
即kobj或其父辈、爷爷辈，都可以发送消息；优先父辈，然后是爷爷辈，以此类推。
*/
const struct kset_uevent_ops *uevent_ops;
} __randomize_layout;
kset通过标准的内核链表（struct list_head list）来管理它的所有子节点，kobject通过kset成员变量指向它的kset容器。
大多数情况下，kobject都是它所属kset(或者严格点，kset内嵌的kobject)的子节点。
2. kobject与kset的关系
下面这张图非常经典。最下面的kobj都属于一个kset，同时这些kobj的父对象就是kset内嵌的kobj。
通过链表，kset可以获取所有属于它的kobj。
从sysfs角度而言，kset代表一个文件夹，而下面的kobj就是这个文件夹里面的内容，而内容有可能是文件也有可能是文件夹。
kobj和kset没有严格的层级关系，也并不是完全的父子关系。如何理解这句话？
kobject之间可以组成一个树形结构：Kobj.parent = kobjkset之间也可以组成一个树形结构，但这是基于kobject实现的：Kset.kobj.parent = Kset'.kobj
正因为
kobj和kset并不是完全的父子关系，因此在注册kobj时，将同时对parent及其所属的kset增加引用计数。
若parent和kset为同一对象，则会对kset增加两次引用计数。
kset算是kobj的“接盘侠”：
- 当
kobj没有所属的parent时，才让kset来接盘当parent； - 如果连
kset也没有，那该kobj属于顶层对象，其sysfs目录将位于/sys/下。
kset内部本身也包含一个kobj对象，在sysfs中也表现为目录；所不同的是，kset要承担kobj状态变动消息的发送任务。因此，首先kset会将所属的kobj组织在kset.list下，同时，通过uevent_ops在合适时候发送消息。
对于kobject_add()来说，它的输入信息是：kobj-parent、kobj-name，kobject_add()优先使用传入的parent作为kobj->parent；其次，使用kset作为kobj->parent。
kobj状态变动后，必须依靠所关联的kset来向用户空间发送消息；若无关联kset（该kobj向上组成的树中，任何成员都无所属的kset），则kobj无法发送用户消息。
kobject 结构可能的层次结构如图：
3. 通过kobject创建bus目录
分析如何通过kobject在/sys创建bus目录。
/*drivers/base/bus.c*/
static int bus_uevent_filter(struct kobject *kobj)
{
const struct kobj_type *ktype = get_ktype(kobj);
if (ktype == &bus_ktype)
return 1;
return 0;
}
static const struct kset_uevent_ops bus_uevent_ops = {
.filter = bus_uevent_filter,
};
int __init buses_init(void)
{
// 直接调用kset_create_and_add，第一个参数为要创建的目录的名字，而第三个参数指定父对象。
bus_kset = kset_create_and_add("bus", &bus_uevent_ops, NULL);
if (!bus_kset)
return -ENOMEM;
system_kset = kset_create_and_add("system", NULL, &devices_kset->kobj);
if (!system_kset)
return -ENOMEM;
return 0;
}
3.1 kset_create_and_add
kset_create_and_add是kobject_create和kobject_add的组合
/*lib/kobject.c*/
/**
* kset_create_and_add() - Create a struct kset dynamically and add it to sysfs.
*
* @name: the name for the kset
* @uevent_ops: a struct kset_uevent_ops for the kset
* @parent_kobj: the parent kobject of this kset, if any.
*
* This function creates a kset structure dynamically and registers it
* with sysfs. When you are finished with this structure, call
* kset_unregister() and the structure will be dynamically freed when it
* is no longer being used.
*
* If the kset was not able to be created, NULL will be returned.
*/
/**
* kobject_create_and_add - 动态创建一个kobject结构并注册到sysfs
*
* @name: kobject的名称
* @parent: kobject的parent kobject of this kobject, 如果有的话
*
* 该方法动态创建一个kobject结构并注册到sysfs。当你完成该结构
* 之后. kobject_del()，这样该结构在不再使用时将会动态的释放。
*
* 如果该kobject无法被创建，将会返回NULL。
*/
struct kset *kset_create_and_add(const char *name,
const struct kset_uevent_ops *uevent_ops,
struct kobject *parent_kobj)
{
struct kset *kset;
int error;
/*创建kset实例，设置某些字段*/
kset = kset_create(name, uevent_ops, parent_kobj);
if (!kset)
return NULL;
/*添加kset到sysfs*/
error = kset_register(kset);
if (error) {
kfree(kset);
return NULL;
}
return kset;
}
EXPORT_SYMBOL_GPL(kset_create_and_add);
/**
* kobject_add() - The main kobject add function.
* @kobj: the kobject to add
* @parent: pointer to the parent of the kobject.
* @fmt: format to name the kobject with.
*
* The kobject name is set and added to the kobject hierarchy in this
* function.
*
* If @parent is set, then the parent of the @kobj will be set to it.
* If @parent is NULL, then the parent of the @kobj will be set to the
* kobject associated with the kset assigned to this kobject. If no kset
* is assigned to the kobject, then the kobject will be located in the
* root of the sysfs tree.
*
* Note, no "add" uevent will be created with this call, the caller should set
* up all of the necessary sysfs files for the object and then call
* kobject_uevent() with the UEVENT_ADD parameter to ensure that
* userspace is properly notified of this kobject's creation.
*
* Return: If this function returns an error, kobject_put() must be
* called to properly clean up the memory associated with the
* object. Under no instance should the kobject that is passed
* to this function be directly freed with a call to kfree(),
* that can leak memory.
*
* If this function returns success, kobject_put() must also be called
* in order to properly clean up the memory associated with the object.
*
* In short, once this function is called, kobject_put() MUST be called
* when the use of the object is finished in order to properly free
* everything.
*/
int kobject_add(struct kobject *kobj, struct kobject *parent,
const char *fmt, ...)
{
va_list args;
int retval;
if (!kobj)
return -EINVAL;
if (!kobj->state_initialized) {
pr_err("kobject '%s' (%p): tried to add an uninitialized object, something is seriously wrong.\n",
kobject_name(kobj), kobj);
dump_stack();
return -EINVAL;
}
va_start(args, fmt);
retval = kobject_add_varg(kobj, parent, fmt, args);
va_end(args);
return retval;
}
EXPORT_SYMBOL(kobject_add);
这里主要调用了两个函数，接下分别来看下。
3.1.1 kset_create
建立kset，设置名字与父对象。
路径：lib/kobject.c
/**
* kset_create() - Create a struct kset dynamically.
*
* @name: the name for the kset
* @uevent_ops: a struct kset_uevent_ops for the kset
* @parent_kobj: the parent kobject of this kset, if any.
*
* This function creates a kset structure dynamically. This structure can
* then be registered with the system and show up in sysfs with a call to
* kset_register(). When you are finished with this structure, if
* kset_register() has been called, call kset_unregister() and the
* structure will be dynamically freed when it is no longer being used.
*
* If the kset was not able to be created, NULL will be returned.
*/
static struct kset *kset_create(const char *name,
const struct kset_uevent_ops *uevent_ops,
struct kobject *parent_kobj)
{
struct kset *kset;
int retval;
/*创建 kset 实例*/
kset = kzalloc(sizeof(*kset), GFP_KERNEL);
if (!kset)
return NULL;
/*设置kobj->name*/
retval = kobject_set_name(&kset->kobj, "%s", name);
if (retval) {
kfree(kset);
return NULL;
}
kset->uevent_ops = uevent_ops;
/*设置父对象*/
kset->kobj.parent = parent_kobj;
/*
* The kobject of this kset will have a type of kset_ktype and belong to
* no kset itself. That way we can properly free it when it is
* finished being used.
*/
kset->kobj.ktype = &kset_ktype;
/*本keset不属于任何kset*/
kset->kobj.kset = NULL;
return kset;
}
这个函数中，动态分配了kset实例，调用kobject_set_name设置kset->kobj->name为bus，也就是我们要创建的目录bus。
同时这里kset->kobj.parent为NULL，也就是没有父对象。
因为要创建的
bus目录是在sysfs所在的根目录创建的，自然没有父对象。
随后简要看下由kobject_set_name函数调用引发的一系列调用。
/*lib/kobject.c*/
/**
* kobject_set_name_vargs() - Set the name of a kobject.
* @kobj: struct kobject to set the name of
* @fmt: format string used to build the name
* @vargs: vargs to format the string.
*/
int kobject_set_name_vargs(struct kobject *kobj, const char *fmt,
va_list vargs)
{
const char *s;
if (kobj->name && !fmt)
return 0;
s = kvasprintf_const(GFP_KERNEL, fmt, vargs);
if (!s)
return -ENOMEM;
/*
* ewww... some of these buggers have '/' in the name ... If
* that's the case, we need to make sure we have an actual
* allocated copy to modify, since kvasprintf_const may have
* returned something from .rodata.
*/
if (strchr(s, '/')) {
char *t;
t = kstrdup(s, GFP_KERNEL);
kfree_const(s);
if (!t)
return -ENOMEM;
strreplace(t, '/', '!');
s = t;
}
kfree_const(kobj->name);
kobj->name = s;
return 0;
}
/*lib/kasprintf.c*/
/* Simplified asprintf. */
char *kvasprintf(gfp_t gfp, const char *fmt, va_list ap)
{
unsigned int first, second;
char *p;
va_list aq;
va_copy(aq, ap);
first = vsnprintf(NULL, 0, fmt, aq);
va_end(aq);
p = kmalloc_track_caller(first+1, gfp);
if (!p)
return NULL;
second = vsnprintf(p, first+1, fmt, ap);
WARN(first != second, "different return values (%u and %u) from vsnprintf(\"%s\", ...)",
first, second, fmt);
return p;
}
EXPORT_SYMBOL(kvasprintf);
3.1.2 kset_register
/*lib/kobject.c*/
/**
* kset_register() - Initialize and add a kset.
* @k: kset.
*/
int kset_register(struct kset *k)
{
int err;
if (!k)
return -EINVAL;
/*初始化kset*/
kset_init(k);
/*在sysfs中建立目录*/
err = kobject_add_internal(&k->kobj);
if (err)
return err;
/* 向用户空间发送 KOBJ_ADD事件。 */
kobject_uevent(&k->kobj, KOBJ_ADD);
return 0;
}
EXPORT_SYMBOL(kset_register);
这里面调用了3个函数。这里先介绍前两个函数。kobject_uevent实现的是用户空间事件传递，留到以后再说。
3.1.2.1 kset_init
该函数用于初始化kset。
/*lib/kobject.c*/
/**
* kset_init() - Initialize a kset for use.
* @k: kset
*/
void kset_init(struct kset *k)
{
/*初始化kobject的某些字段*/
kobject_init_internal(&k->kobj);
/*初始化链表头*/
INIT_LIST_HEAD(&k->list);
/*初始化自旋锁*/
spin_lock_init(&k->list_lock);
}
/* 设置初始化状态 */
static void kobject_init_internal(struct kobject *kobj)
{
if (!kobj)
return;
/*初始化引用基计数*/
kref_init(&kobj->kref);
/*初始化链表头*/
INIT_LIST_HEAD(&kobj->entry);
// 记录kobj是否注册到sysfs，在kobject_add_internal()中置位。
kobj->state_in_sysfs = 0;
// 当发送KOBJ_ADD消息时，置位。提示已经向用户空间发送ADD消息。
kobj->state_add_uevent_sent = 0;
// 当发送KOBJ_REMOVE消息时，置位。提示已经向用户空间发送REMOVE消息。
kobj->state_remove_uevent_sent = 0;
// 标记已经初始化了。
kobj->state_initialized = 1;
}
3.1.2.2 kobject_add_internal
该函数将在sysfs中建立目录。
kobject_add_internal()会根据kobj.parent和kobj.kset来综合决定父对象（相当于/sysfs中的父级目录）：
- 如果有
parent则默认parent为父对象； - 如果没有
parent作为父对象，但是有当前的kobj位于kset中，则使用kset中的kobj作为父对象 - 如果没有
parent也没有kset作为父对象，那该kobj属于顶层对象：在sysfs中，我们可以看到kobj位于/sys/下。
/*lib/kobject.c*/
static int kobject_add_internal(struct kobject *kobj)
{
int error = 0;
struct kobject *parent;
if (!kobj)
return -ENOENT;
/*检查name字段是否存在*/
if (!kobj->name || !kobj->name[0]) {
return -EINVAL;
}
/*有父对象则增加父对象引用计数*/
parent = kobject_get(kobj->parent);
/* join kset if set, use it as parent if we do not already have one */
/*
由于在kset_create中有kset->kobj.kset = NULL，
因此if (kobj->kset)条件不满足。
*/
if (kobj->kset) {
if (!parent)
/*kobj属于某个kset，但是该kobj没有父对象，则以kset的kobj作为父对象*/
parent = kobject_get(&kobj->kset->kobj);
/*将kojbect添加到kset结构中的链表当中*/
kobj_kset_join(kobj);
/* 根据kobj.parent和kobj.kset来综合决定父对象*/
kobj->parent = parent;
}
pr_debug("kobject: '%s' (%p): %s: parent: '%s', set: '%s'\n",
kobject_name(kobj), kobj, __func__,
parent ? kobject_name(parent) : "<NULL>",
kobj->kset ? kobject_name(&kobj->kset->kobj) : "<NULL>");
/*根据kobj->name在sys中建立目录*/
error = create_dir(kobj);
// 如果出错时，回收资源
if (error) {
/* 把kobj从kobj->kset的链表中去除 */
// 对应于 kobj_kset_join
kobj_kset_leave(kobj);
kobject_put(parent);
kobj->parent = NULL;
/* be noisy on error issues */
if (error == -EEXIST)
WARN(1, "%s failed for %s with "
"-EEXIST, don't try to register things with "
"the same name in the same directory.\n",
__func__, kobject_name(kobj));
else
WARN(1, "%s failed for %s (error: %d parent: %s)\n",
__func__, kobject_name(kobj), error,
parent ? kobject_name(parent) : "'none'");
} else
kobj->state_in_sysfs = 1;
return error;
}
因此在这个函数中，对name进行了必要的检查之后，调用了create_dir在sysfs中创建目录。
在create_dir执行完成以后会在sysfs的根目录（/sys/）建立文件夹bus。该函数的详细分析将在后面给出。
至此，对bus目录的建立有了简单而直观的了解。
我们可以看出kset其实就是表示一个文件夹，而kset本身也含有一个kobject，而该kobject的name字段即为该目录的名字，本例中为bus。
4. kobj/kset功能特性
我们先大概提一下这些功能特性，在后面的文章中会详细说明：对象生命周期管理以及用户空间事件投递。
4.1 对象生命周期管理
在创建一个kobj对象时，kobj中的引用计数管理成员kref被初始化为1；从此kobj可以使用下面的API函数来进行生命周期管理：
/*lib/kobject.c*/
/**
* kobject_get() - Increment refcount for object.
* @kobj: object.
*/
struct kobject *kobject_get(struct kobject *kobj)
{
if (kobj) {
if (!kobj->state_initialized)
WARN(1, KERN_WARNING
"kobject: '%s' (%p): is not initialized, yet kobject_get() is being called.\n",
kobject_name(kobj), kobj);
kref_get(&kobj->kref);
}
return kobj;
}
EXPORT_SYMBOL(kobject_get);
/**
* kobject_put() - Decrement refcount for object.
* @kobj: object.
*
* Decrement the refcount, and if 0, call kobject_cleanup().
*/
void kobject_put(struct kobject *kobj)
{
if (kobj) {
if (!kobj->state_initialized)
WARN(1, KERN_WARNING
"kobject: '%s' (%p): is not initialized, yet kobject_put() is being called.\n",
kobject_name(kobj), kobj);
kref_put(&kobj->kref, kobject_release);
}
}
EXPORT_SYMBOL(kobject_put);
static void dynamic_kobj_release(struct kobject *kobj)
{
pr_debug("kobject: (%p): %s\n", kobj, __func__);
kfree(kobj);
}
对于kobject_get()，它就是直接使用kref_get()接口来对引用计数进行加1操作；
而对于kobject_put()，它不仅要使用kref_put()接口来对引用计数进行减1操作，还要对生命终结的对象执行release()操作：当引用计数减为0时，回收该对象的资源。
然而kobject是高度抽象的实体，导致kobject不会单独使用，而是嵌在具体对象中。反过来也可以这样理解：凡是需要做对象生命周期管理的对象，都可以通过内嵌kobject来实现需求。
4.1.1 kobject在kobject_put的资源回收是如何实现的？
实际上，kobject_put()通常被具体对象做一个简单包装，如：bus_put()，它直接调用kset_put()，然后调用到kobject_put()。
那对于这个bus_type对象而言，仅仅通过kobject_put()，如何来达到释放整个bus_type的目的呢？这里就需要kobject另一个成员struct kobj_type * ktype来完成。
当引用计数为0时，kobject核心会调用kobject_release()，最后会调用kobj_type->release(kobj)来完成对象的释放。可是具体对象的释放，最后却通过kobj->kobj_type->release()来释放，那这个release()函数，就必须得由具体的对象来指定。
还是拿bus_type举例：
在通过bus_register(struct bus_type *bus)进行总线注册时，该API内部会执行priv->subsys.kobj.ktype = &bus_ktype操作；
// driver/base/bus.c
int bus_register(struct bus_type *bus)
{
// ...
priv->subsys.kobj.ktype = &bus_ktype;
// ...
}
有了该操作，那么前面的bus_put()在执行bus_type->p-> subsys.kobj->ktype->release()时，就会执行上面注册的bus_ktype.release = bus_release函数；
// driver/base/bus.c
static struct kobj_type bus_ktype = {
.sysfs_ops = &bus_sysfs_ops,
.release = bus_release,
};
static void bus_release(struct kobject *kobj)
{
// 获取整个 具体的 bus子系统 对象
struct subsys_private *priv = to_subsys_private(kobj);
struct bus_type *bus = priv->bus;
// 释放资源
kfree(priv);
bus->p = NULL;
}
由于bus_release()函数由具体的bus子系统提供，它必定知道如何释放包括kobj在内的bus_type对象。
5. sysfs文件系统的层次组织
sysfs向用户空间展示了驱动设备的层次结构。这一个功能比较简单，先完全贴出来。
我们都知道设备和对应的驱动都是由内核管理的，这些对于用户空间是不可见的。现在通过sysfs，可以在用户空间直观的了解设备驱动的层次结构。
实际上，sysfs文件系统的组织功能是基于kobject实现的：该功能依靠kobj的parent、kset、sd等成员来完成。sysfs文件系统能够以友好的界面，将kobj所刻画的对象层次、所属关系、属性值，展现在用户空间。
我们来看看sysfs的文件结构：
uos@uos-PC:~$ uname -r
4.19.0-loongson-3-desktop
uos@uos-PC:~$ ls /sys
block bus class dev devices firmware fs kernel module power
| 目录 | 意义 |
|---|---|
| block | 块设备 |
| bus | 系统中的总线 |
| class | 设备类型，比如输入设备 |
| dev | 系统中已注册的设备节点的视图，有两个子目录char和block。 |
| devices | 系统中所有设备拓扑结构视图 |
| fireware | 固件 |
| fs | 文件系统 |
| kernel | 内核配置选项和状态信息 |
| module | 模块 |
| power | 系统的电源管理数据 |
6. 用户空间事件投递
实际上，当具体对象有事件发生时，相应的操作函数中（如device_add()），会调用事件消息接口kobject_uevent()。在该接口中，首先会添加一些共性的消息（路径、子系统名等），然后会找寻合适的kset->uevent_ops，并调用该ops->uevent(kset, kobj, env)来添加该对象特有的事件消息（如device对象的设备号、设备名、驱动名、DT信息），一切准备完毕，就会通过两种可能的方法向用户空间发送消息：1.netlink广播；2. uevent_helper程序。
因此，上面具体对象的事件消息填充函数，应该由特定对象来填充；对于device对象来说，在初始化的时候，通过下面这行代码：
devices_kset = kset_create_and_add("devices", &device_uevent_ops, NULL);
来完成kset->uevent_ops的指定，今后所有设备注册时，调用device_register()-->device_initialize()后，都将导致：
dev->kobj.kset = devices_kset;
因此通过device_register()注册的设备，在调用kobject_uevent()接口发送事件消息时，就自动会调用devices_kset的device_uevent_ops。该ops的uevent()方法定义如下：
static const struct kset_uevent_ops device_uevent_ops = {
.filter = dev_uevent_filter,
.name = dev_uevent_name,
.uevent = dev_uevent,
}; ||
\/
dev_uevent(struct kset *kset, struct kobject *kobj, struct kobj_uevent_env *env)
add_uevent_var(env, "xxxxxxx", ....)
add_uevent_var(env, "xxxxxxx", ....)
add_uevent_var(env, "xxxxxxx", ....)
....
if (dev->bus && dev->bus->uevent)
dev->bus->uevent(dev, env) //通过总线的uevent()方法，发送设备状态改变的事件消息
if (dev->class && dev->class->dev_uevent)
dev->class->dev_uevent(dev, env)
if (dev->type && dev->type->uevent)
dev->type->uevent(dev, env)
在该ops的uevent()方法中，会分别调用bus、class、device type的uevent方法来生成事件消息。
7. kobject总结
kobject可以看成是一个基类，这个基类通过ktype属性实现了资源回收的功能，至于kset，负责记录一组kobject，我们将其看成是一个集合，负责事件管理。
从此，其他对象就可以通过包含kobject来实现上层的功能。
8. sysfs
sysfs 是一个基于内存的虚拟的文件系统，由kernel提供，挂载到 /sys 目录下(用 mount 查看得到 sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime))，负责以设备树的形式向 user space 提供直观的设备和驱动信息。
8.1 对象模型体系
sysfs（system filesystem）是一个处于内存中的虚拟文件系统，为我们提供了kobject对象层次结构的视图。以一个简单的文件系统的方式来观察系统中各种设备的拓扑结构。
sysfs是用于表现设备驱动模型的文件系统，它基于ramfs。要学习linux的设备驱动模型，就要先做好底层工作，总结sysfs提供给外界的API就是其中之一。
sysfs文件系统中提供了四类文件的创建与管理，分别是目录、普通文件、软链接文件、二进制文件。
- 目录层次往往代表着设备驱动模型的结构
- 软链接文件则代表着不同部分间的关系。比如某个设备的目录只出现在
/sys/devices下，其它地方涉及到它时只好用软链接文件链接过去，保持了设备唯一的实例。 - 普通文件和二进制文件往往代表了设备的属性，读写这些文件需要调用相应的属性读写。
sysfs是表现设备驱动模型的文件系统，它的目录层次实际反映的是对象的层次。为了配合这种目录，linux专门提供了两个结构作为sysfs的骨架，它们就是struct kobject和struct kset。
我们知道，sysfs是完全虚拟的，它的每个目录其实都对应着一个kobject，要想知道这个目录下有哪些子目录，就要用到kset。从面向对象的角度来讲，kset继承了kobject的功能，既可以表示sysfs中的一个目录，还可以包含下层目录。
dentry结构体表示目录项，通过连接kobject到指定的目录项上，无疑方便的将kobject映射到该目录上。
因此，kobjects其实已经形成了一棵树了——就是对象模型体系。
由于kobject被映射到目录项，同时对象层次结构也已经在内存中形成了一棵树，因此sysfs就诞生了。
uos@uos-PC:~$ tree /sys | head -n 300
/sys
├── block
│ └── nvme0n1 -> ../devices/pci0000:00/0000:00:13.0/0000:05:00.0/nvme/nvme0/nvme0n1
├── bus
│ ├── acpi
│ │ ├── devices
│ │ │ ├── ACPI0003:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/ACPI0003:00
│ │ │ ├── ACPI0007:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0007:00
│ │ │ ├── ACPI0007:01 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0007:01
│ │ │ ├── ACPI0007:02 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0007:02
│ │ │ ├── ACPI0007:03 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0007:03
│ │ │ ├── device:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00
│ │ │ ├── device:01 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01
│ │ │ ├── device:02 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/device:02
│ │ │ ├── device:03 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:03
│ │ │ ├── device:04 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:03/device:04
│ │ │ ├── device:05 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:03/device:04/device:05
│ │ │ ├── device:06 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:03/device:04/device:06
│ │ │ ├── device:07 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:03/device:04/device:07
│ │ │ ├── device:08 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08
│ │ │ ├── device:09 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/device:09
│ │ │ ├── device:0a -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/device:09/device:0a
│ │ │ ├── device:0b -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/device:09/device:0b
│ │ │ ├── device:0c -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/device:09/device:0c
│ │ │ ├── device:0d -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d
│ │ │ ├── device:0e -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e
│ │ │ ├── device:0f -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f
│ │ │ ├── device:10 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:10
│ │ │ ├── device:11 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:11
│ │ │ ├── device:12 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:12
│ │ │ ├── device:13 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:12/device:13
│ │ │ ├── device:14 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:12/device:13/device:14
│ │ │ ├── device:15 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:12/device:13/device:15
│ │ │ ├── device:16 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:12/device:13/device:16
│ │ │ ├── device:17 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17
│ │ │ ├── device:18 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18
│ │ │ ├── device:19 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19
│ │ │ ├── device:1a -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/device:1a
│ │ │ ├── device:1b -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1b
│ │ │ ├── device:1c -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1b/device:1c
│ │ │ ├── device:1d -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1d
│ │ │ ├── device:1e -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1d/device:1e
│ │ │ ├── IPI0001:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/IPI0001:00
│ │ │ ├── LEN2020:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/LEN2020:00
│ │ │ ├── LNXPOWER:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/LNXPOWER:00
│ │ │ ├── LNXPOWER:01 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/LNXPOWER:01
│ │ │ ├── LNXPWRBN:00 -> ../../../devices/LNXSYSTM:00/LNXPWRBN:00
│ │ │ ├── LNXSYBUS:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00
│ │ │ ├── LNXSYBUS:01 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:01
│ │ │ ├── LNXSYSTM:00 -> ../../../devices/LNXSYSTM:00
│ │ │ ├── LNXTHERM:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:01/LNXTHERM:00
│ │ │ ├── LOON0000:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/LOON0000:00
│ │ │ ├── LOON0001:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/LOON0001:00
│ │ │ ├── LOON0002:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/LOON0002:00
│ │ │ ├── LOON0004:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/LOON0004:00
│ │ │ ├── LOON0004:01 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/LOON0004:01
│ │ │ ├── LOON0004:02 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/LOON0004:02
│ │ │ ├── LOON0004:03 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/LOON0004:03
│ │ │ ├── LOON0004:04 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/LOON0004:04
│ │ │ ├── LOON0006:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/LOON0006:00
│ │ │ ├── LOON0006:01 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/LOON0006:01
│ │ │ ├── LOON0006:02 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/LOON0006:02
│ │ │ ├── LOON0006:03 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/LOON0006:03
│ │ │ ├── PNP0303:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0303:00
│ │ │ ├── PNP0501:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0501:00
│ │ │ ├── PNP0501:01 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0501:01
│ │ │ ├── PNP0501:02 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0501:02
│ │ │ ├── PNP0501:03 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0501:03
│ │ │ ├── PNP0501:04 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0501:04
│ │ │ ├── PNP0A08:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00
│ │ │ ├── PNP0C09:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00
│ │ │ └── PNP0C0A:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/PNP0C0A:00
│ │ ├── drivers
│ │ │ ├── ac
│ │ │ │ ├── ACPI0003:00 -> ../../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/ACPI0003:00
│ │ │ │ ├── bind
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── battery
│ │ │ │ ├── bind
│ │ │ │ ├── PNP0C0A:00 -> ../../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/PNP0C0A:00
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── button
│ │ │ │ ├── bind
│ │ │ │ ├── LNXPWRBN:00 -> ../../../../devices/LNXSYSTM:00/LNXPWRBN:00
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── ec
│ │ │ │ ├── bind
│ │ │ │ ├── PNP0C09:00 -> ../../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── loongson-laptop_EC Event
│ │ │ │ ├── bind
│ │ │ │ ├── LOON0000:00 -> ../../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/LOON0000:00
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── thermal
│ │ │ │ ├── bind
│ │ │ │ ├── LNXTHERM:00 -> ../../../../devices/LNXSYSTM:00/LNXSYBUS:01/LNXTHERM:00
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ └── tpm_crb
│ │ │ ├── bind
│ │ │ ├── uevent
│ │ │ └── unbind
│ │ ├── drivers_autoprobe
│ │ ├── drivers_probe
│ │ └── uevent
│ ├── clockevents
│ │ ├── devices
│ │ │ ├── clockevent0 -> ../../../devices/system/clockevents/clockevent0
│ │ │ ├── clockevent1 -> ../../../devices/system/clockevents/clockevent1
│ │ │ ├── clockevent2 -> ../../../devices/system/clockevents/clockevent2
│ │ │ └── clockevent3 -> ../../../devices/system/clockevents/clockevent3
│ │ ├── drivers
│ │ ├── drivers_autoprobe
│ │ ├── drivers_probe
│ │ └── uevent
│ ├── clocksource
│ │ ├── devices
│ │ │ └── clocksource0 -> ../../../devices/system/clocksource/clocksource0
│ │ ├── drivers
│ │ ├── drivers_autoprobe
│ │ ├── drivers_probe
│ │ └── uevent
│ ├── container
│ │ ├── devices
│ │ ├── drivers
│ │ ├── drivers_autoprobe
│ │ ├── drivers_probe
│ │ └── uevent
│ ├── cpu
│ │ ├── devices
│ │ │ ├── cpu0 -> ../../../devices/system/cpu/cpu0
│ │ │ ├── cpu1 -> ../../../devices/system/cpu/cpu1
│ │ │ ├── cpu2 -> ../../../devices/system/cpu/cpu2
│ │ │ └── cpu3 -> ../../../devices/system/cpu/cpu3
│ │ ├── drivers
│ │ │ └── processor
│ │ │ ├── bind
│ │ │ ├── cpu0 -> ../../../../devices/system/cpu/cpu0
│ │ │ ├── cpu1 -> ../../../../devices/system/cpu/cpu1
│ │ │ ├── cpu2 -> ../../../../devices/system/cpu/cpu2
│ │ │ ├── cpu3 -> ../../../../devices/system/cpu/cpu3
│ │ │ ├── uevent
│ │ │ └── unbind
│ │ ├── drivers_autoprobe
│ │ ├── drivers_probe
│ │ └── uevent
│ ├── event_source
│ │ ├── devices
│ │ │ ├── cpu -> ../../../devices/cpu
│ │ │ ├── kprobe -> ../../../devices/kprobe
│ │ │ ├── software -> ../../../devices/software
│ │ │ ├── tracepoint -> ../../../devices/tracepoint
│ │ │ └── uprobe -> ../../../devices/uprobe
│ │ ├── drivers
│ │ ├── drivers_autoprobe
│ │ ├── drivers_probe
│ │ └── uevent
│ ├── genpd
│ │ ├── devices
│ │ ├── drivers
│ │ ├── drivers_autoprobe
│ │ ├── drivers_probe
│ │ └── uevent
│ ├── gpio
│ │ ├── devices
│ │ │ └── gpiochip0 -> ../../../devices/platform/LOON0002:00/gpiochip0
│ │ ├── drivers
│ │ ├── drivers_autoprobe
│ │ ├── drivers_probe
│ │ └── uevent
│ ├── hdaudio
│ │ ├── devices
│ │ │ ├── hdaudioC0D0 -> ../../../devices/pci0000:00/0000:00:06.2/hdaudioC0D0
│ │ │ ├── hdaudioC0D1 -> ../../../devices/pci0000:00/0000:00:06.2/hdaudioC0D1
│ │ │ └── hdaudioC1D0 -> ../../../devices/pci0000:00/0000:00:07.0/hdaudioC1D0
│ │ ├── drivers
│ │ │ ├── snd_hda_codec_analog
│ │ │ │ ├── bind
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── snd_hda_codec_ca0110
│ │ │ │ ├── bind
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── snd_hda_codec_ca0132
│ │ │ │ ├── bind
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── snd_hda_codec_cirrus
│ │ │ │ ├── bind
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── snd_hda_codec_cmedia
│ │ │ │ ├── bind
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── snd_hda_codec_conexant
│ │ │ │ ├── bind
│ │ │ │ ├── hdaudioC1D0 -> ../../../../devices/pci0000:00/0000:00:07.0/hdaudioC1D0
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── snd_hda_codec_generic
│ │ │ │ ├── bind
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── snd_hda_codec_hdmi
│ │ │ │ ├── bind
│ │ │ │ ├── hdaudioC0D0 -> ../../../../devices/pci0000:00/0000:00:06.2/hdaudioC0D0
│ │ │ │ ├── hdaudioC0D1 -> ../../../../devices/pci0000:00/0000:00:06.2/hdaudioC0D1
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── snd_hda_codec_idt
│ │ │ │ ├── bind
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── snd_hda_codec_realtek
│ │ │ │ ├── bind
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── snd_hda_codec_si3054
│ │ │ │ ├── bind
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ └── snd_hda_codec_via
│ │ │ ├── bind
│ │ │ ├── uevent
│ │ │ └── unbind
│ │ ├── drivers_autoprobe
│ │ ├── drivers_probe
│ │ └── uevent
│ ├── hid
│ │ ├── devices
│ │ │ └── 0003:1C4F:0048.0001 -> ../../../devices/pci0000:00/0000:00:05.0/usb6/6-1/6-1:1.0/0003:1C4F:0048.0001
│ │ ├── drivers
│ │ │ └── hid-generic
│ │ │ ├── 0003:1C4F:0048.0001 -> ../../../../devices/pci0000:00/0000:00:05.0/usb6/6-1/6-1:1.0/0003:1C4F:0048.0001
│ │ │ ├── bind
│ │ │ ├── module -> ../../../../module/hid_generic
│ │ │ ├── new_id
│ │ │ ├── uevent
│ │ │ └── unbind
│ │ ├── drivers_autoprobe
│ │ ├── drivers_probe
│ │ └── uevent
│ ├── i2c
│ │ ├── devices
│ │ │ ├── 0-0050 -> ../../../devices/pci0000:00/0000:00:06.1/i2c-0/0-0050
│ │ │ ├── 6-0050 -> ../../../devices/pci0000:00/0000:00:06.1/i2c-6/6-0050
│ │ │ ├── i2c-0 -> ../../../devices/pci0000:00/0000:00:06.1/i2c-0
│ │ │ ├── i2c-1 -> ../../../devices/platform/LOON0004:00/i2c-1
│ │ │ ├── i2c-2 -> ../../../devices/platform/LOON0004:01/i2c-2
│ │ │ ├── i2c-3 -> ../../../devices/platform/LOON0004:02/i2c-3
│ │ │ ├── i2c-4 -> ../../../devices/platform/LOON0004:03/i2c-4
│ │ │ ├── i2c-5 -> ../../../devices/platform/LOON0004:04/i2c-5
│ │ │ └── i2c-6 -> ../../../devices/pci0000:00/0000:00:06.1/i2c-6
│ │ ├── drivers
│ │ │ ├── dummy
│ │ │ │ ├── bind
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ ├── ipmi_ssif
│ │ │ │ ├── bind
│ │ │ │ ├── module -> ../../../../module/ipmi_ssif
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ └── pca953x
│ │ │ ├── bind
│ │ │ ├── uevent
│ │ │ └── unbind
│ │ ├── drivers_autoprobe
│ │ ├── drivers_probe
│ │ └── uevent
│ ├── isa
│ │ ├── devices
│ │ ├── drivers
│ │ ├── drivers_autoprobe
│ │ ├── drivers_probe
│ │ └── uevent
│ ├── mdio_bus
│ │ ├── devices
│ │ ├── drivers
│ │ │ ├── Generic 10G PHY
│ │ │ │ ├── bind
│ │ │ │ ├── uevent
│ │ │ │ └── unbind
│ │ │ └── Generic PHY
│ │ │ ├── bind
│ │ │ ├── uevent
│ │ │ └── unbind
│ │ ├── drivers_autoprobe
│ │ ├── drivers_probe
│ │ └── uevent
│ ├── memory
│ │ ├── devices
│ │ │ ├── memory0 -> ../../../devices/system/memory/memory0
sysfs的根目录下包含了七个目录：block、bus、class、devices、firmware、module和power。
block目录下的每个子目录都对应着系统的一个块设备。bus目录提供了一个系统总线视图。class目录包含了以高层功能逻辑组织起来的系统设备视图。devices目录是系统中设备拓扑结构视图，它直接映射除了内核中设备结构体的组织层次。firmware目录包含了一些诸如ACPI、EDD、EFI等低层子系统的特殊树。power目录包含了系统范围的电源管理数据。- 最重要的目录是
devices，该目录将设备模型导出到用户空间。目录结构就是系统中实际的设备拓扑。kernel 包括了一些内核的可调参数等信息，和devices目录关联性没那么强。
注意，其他目录中的很多数据都是将devices目录下的数据加以转换加工而得；
因此，在class章节中，我们会看到一些软链接的创建，其实就是为了优雅地归对设备进行归类。
8.2 sysfs中添加和删除kobject
8.2.1 导入kobject到sysfs
仅仅初始化kobjcet是不能自动将其导出到sysfs中的，想要把kobject导入sysfs，需要用到函数kobject_add()：
需要注意的是，并不是说每一个
kobject对象都需要在sysfs中表示，但是每一个被注册到系统中的kset都会被添加到sysfs文件系统中。
一个kset对象就对应一个/sys中的一个目录，kset中的每一个kobject成员，都对应sysfs中一个文件或者一个目录。
#include <linux/kobject.h>
#if 0 // 下面两种操作等价
void kobject_init(struct kobject *kobj, struct kobj_type *ktype);
int kobject_add(struct kobject *kobj);
#else
struct kobject *kobject_create_and_add(const char *name, struct kobject *parent);
// 再也没有 kobject_register 这个函数了
#endif
kobject在sysfs中的位置取决于kobject在对象层次结构中的位置。如果kobject的父指针被设置，那么在sysfs中的kobject将被映射为其父目录下的子目录。如果parent没有设置，那么kobject将被映射为kset->kobj中的子目录。
如果给定的kobject中parent或kset字段都没有设置，那么就认为kobject没有父对象，所以就会被映射成sysfs下的根级目录。但这往往不是你所需要的，所以在调用kobject_add()前parent或kset字段应该显示的设置。
不管怎样，sysfs中代表kobject的目录名字是由kobj->k_name指定的。
不过不需要调用kobject_init()和kobject_add()，因为系统提供了函数kobject_create_and_add()。
该函数既初始化了给定的kobject对象，同时又将其加入到对象层次结构中。
8.2.1.1 kobj/kset的引用计数示例
下图展示了一个顶层kobj/kset，通过不断的添加子节点，导致的引用计数变化情况。
首先在（I）中建立了顶层对象A，其kref初始化为1；在第（II）步中，建立了A的子对象B，此时A对象的kref引用计数加1变为2；在第（III）步中，继续在A下建立子对象C，此时A对象的kref引用计数加1变为3；在第（IV）步中，建立B对象的子对象D，此时，只会对D的父对象进行引用计数加1；而对更上层的父对象，则不进行引用加1操作。
8.2.1.2 platform_bus_type的注册示例
内核启动时，会在初始化阶段进行platform_bus_type总线的注册：bus_register(&platform_bus_type)。在该函数里，会设置platform_bus_type->p->subsys.kobj.kset = bus_kset、platform_bus_type->p->subsys.kobj.ktype = &bus_ktype，因此按照前面的总结，由于platform_bus_type有kset、无parent，导致该bus注册进系统后，其kset引用计数将被增加两次，同时，在bus_kset对应的目录（/sys/bus/）下建立platform_bus_type对应的子目录（/sys/bus/platform/）。同理，当该总线的引用计数为0时，将导致该对象生命的终结，会触发release()操作，显然该操作将导致bus_kset的引用计数减少两次。
8.2.2 从sysfs删除kobject
/*lib/kobject.c*/
/**
* kobject_del() - Unlink kobject from hierarchy.
* @kobj: object.
*
* This is the function that should be called to delete an object
* successfully added via kobject_add().
*/
void kobject_del(struct kobject *kobj)
{
struct kobject *parent;
if (!kobj)
return;
parent = kobj->parent;
__kobject_del(kobj);
kobject_put(parent);
}
EXPORT_SYMBOL(kobject_del);
从sysfs中删除一个kobject对应文件目录。需使用函数kobject_del()，内部会自动使用put来让引用减一。
以前的版本需要再调用一次
kobject_put；但现在不需要了。
8.2.3 向sysfs中添加文件
kobject已经被映射为文件目录。所有的对象层次一个不少的映射成sys下的目标结构。
sysfs仅仅是一个漂亮的树，但是没有提供实际数据的文件。
因此，需要kobj_type来进行支持，有关sysfs的成员如下：
/*include/linux/kobject.h*/
struct kobj_type {
void (*release)(struct kobject *kobj);
/* 该类型kobj的sysfs操作接口。 */
const struct sysfs_ops *sysfs_ops;
/* 该类型kobj自带的缺省属性（文件），这些属性文件在注册kobj时，直接pop为该目录下的文件。 */
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);
};
8.2.3.1 默认属性attribute
默认的文件集合是通过Kobject和kset的ktype字段提供的。因此所有具有相同类型的kobject在它们对应的sysfs目录下都拥有相同的默认文件集合。
kobj_type字段含有一个字段——default_attrs，它是一个attribute结构体数组。这些属性负责将内核数据映射成sysfs中的文件。
8.2.3.1.1 attribute原型
/*include/linux/sysfs.h*/
struct attribute {
const char *name;
umode_t mode;
#ifdef CONFIG_DEBUG_LOCK_ALLOC
bool ignore_lockdep:1;
struct lock_class_key *key;
struct lock_class_key skey;
#endif
};
/**
* struct attribute_group - data structure used to declare an attribute group.
* @name: Optional: Attribute group name
* If specified, the attribute group will be created in
* a new subdirectory with this name.
* @is_visible: Optional: Function to return permissions associated with an
* attribute of the group. Will be called repeatedly for each
* non-binary attribute in the group. Only read/write
* permissions as well as SYSFS_PREALLOC are accepted. Must
* return 0 if an attribute is not visible. The returned value
* will replace static permissions defined in struct attribute.
* @is_bin_visible:
* Optional: Function to return permissions associated with a
* binary attribute of the group. Will be called repeatedly
* for each binary attribute in the group. Only read/write
* permissions as well as SYSFS_PREALLOC are accepted. Must
* return 0 if a binary attribute is not visible. The returned
* value will replace static permissions defined in
* struct bin_attribute.
* @attrs: Pointer to NULL terminated list of attributes.
* @bin_attrs: Pointer to NULL terminated list of binary attributes.
* Either attrs or bin_attrs or both must be provided.
*/
struct attribute_group {
/* 属性名称 */
const char *name;
umode_t (*is_visible)(struct kobject *,
struct attribute *, int);
umode_t (*is_bin_visible)(struct kobject *,
struct bin_attribute *, int);
struct attribute **attrs;
struct bin_attribute **bin_attrs;
};
其中，name：提供了该属性的名称，最终出现在sysfs中的文件名就是它。
mode字段类型为mode_t，它表示了sysfs中该文件的权限。
- 对于只读属性而言，如果是所有人都可读它，那么该字段设为
S_IRUGO; - 如果只限于所有者可读，则该字段设置为
S_IRUSR。 - 同样对于可写属性，可能会设置该字段为
S_IRUGO|S_IWUSR。 sysfs中的所有文件和目录的uid与gid标志均为零。
8.2.3.1.2 如何理解属性？
uos@uos-PC:~$ ls /sys/class/leds/input0::capslock/
brightness device max_brightness power subsystem trigger uevent
其中，brightness、trigger这些文件就是属性，以文件的形式提供。
8.2.3.1.3 属性读写方法sysfs_ops
虽然default_attrs列出了默认的属性，sysfs_ops则描述了如何使用它们。
#include <linux/sysfs.h>
struct sysfs_ops {
/* 读取该 sysfs 文件时该方法被调用 */
ssize_t (*show)(struct kobject *, struct attribute *, char *);
/* 写入该 sysfs 文件时该方法被调用 */
ssize_t (*store)(struct kobject *, struct attribute *, const char *, size_t);
};
struct sysfs_ops中包含show和store两个函数指针，它们分别在sysfs文件读和文件写时调用。
8.2.3.1.4 创建/删除新属性
一些特别情况下会碰到特殊的kobject实例，它希望（甚至必须）有自己的属性——也许是通用属性没包含那些需要的数据或者函数。
因此使用sysfs_create_file()接口在默认集合上添加新属性：
#include <linux/sysfs.h>
int sysfs_create_file(struct kobject *kobj,
const struct attribute *attr);
int sysfs_create_files(struct kobject *kobj,
const struct attribute **attr);
void sysfs_remove_file(struct kobject *kobj,
const struct attribute *attr)
这个接口通过attr参数指向相应的attribute结构体，而参数kobj则指定了属性所在的kobject对象。
在该函数被调用之前，给定的属性将被赋值，如果成功，该函数返回零。否则返回负的错误码。
kobject中ktype.sysfs_ops操作将负责处理新属性。现有的show()和store()方法必须能够处理新属性。
删除一个属性通过函数sysfs_remove_file()完成：一旦调用sysfs_remove_file，给定的属性将不复存在于给定的kobject目录中。
8.2.3.1.5 创建/删除软链接
除了添加文件外，可能还要创建符号连接。在sysfs中创建一个符号连接方式。
int sysfs_create_link(struct kobject *kobj, struct kobject *target,
const char *name);
int sysfs_create_link_nowarn(struct kobject *kobj,
struct kobject *target,
const char *name);
该函数创建的符号连接名由name指定，连接则由kobj对应的目录映射到target指定的目录。如果成功，则返回零，如果失败，返回负的错误码。
而由sysfs_create_link()创建的符号连接可通过函数sysfs_remove_link()删除：
void sysfs_remove_link(struct kobject *kobj, const char *name);
// 一旦调用返回，给定的连接将不复存在于给定的kobject目录中。
8.2.3.2 sysfs约定
首先sysfs属性应该保证每个属性文件只导出一个值，该值应该是文本形式而且被映射为简单C类型。其次，在sysfs中要以一个清晰的层次组织数据。最后，记住sysfs提供内核到用户空间的服务，这多少有些用户空间的ABI（应用程序二进制接口）的作用。
9. 附录：kobject创建
9.1 简单创建kobj以及添加
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/kobject.h>
struct kobject *g_obj = NULL;
struct kobject *g_parobj = NULL;
static int __init test_init(void)
{
g_parobj = kobject_create_and_add("dog",NULL);
if(NULL == g_parobj)
{
printk("create kobj error\n");
return -1;
}
g_obj = kobject_create_and_add("whitedog",g_parobj);
if(NULL == g_obj)
{
if(g_parobj)
{
kobject_del(g_parobj);
kobject_put(g_parobj);
}
}
return 0;
}
static void __exit test_exit(void)
{
if(g_obj)
{
kobject_del(g_obj);
kobject_put(g_obj);
}
if(g_parobj)
{
kobject_del(g_parobj);
kobject_put(g_parobj);
}
return;
}
module_init(test_init);
module_exit(test_exit);
MODULE_LICENSE("GPL");
9.2 内核kobj例子
代码来自：samples/kobject/kobject-example.c
可能会遇到error: negative width in bit-field ‘’这个错误，需要将__ATTR中的666权限改为664。
// SPDX-License-Identifier: GPL-2.0
/*
* Sample kobject implementation
*
* Copyright (C) 2004-2007 Greg Kroah-Hartman <greg@kroah.com>
* Copyright (C) 2007 Novell Inc.
*/
#include <linux/kobject.h>
#include <linux/string.h>
#include <linux/sysfs.h>
#include <linux/module.h>
#include <linux/init.h>
/*
* This module shows how to create a simple subdirectory in sysfs called
* /sys/kernel/kobject-example In that directory, 3 files are created:
* "foo", "baz", and "bar". If an integer is written to these files, it can be
* later read out of it.
*/
static int foo;
static int baz;
static int bar;
/*
* The "foo" file where a static variable is read from and written to.
*/
static ssize_t foo_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
{
return sysfs_emit(buf, "%d\n", foo);
}
static ssize_t foo_store(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t count)
{
int ret;
ret = kstrtoint(buf, 10, &foo);
if (ret < 0)
return ret;
return count;
}
/* Sysfs attributes cannot be world-writable. */
static struct kobj_attribute foo_attribute =
__ATTR(foo, 0664, foo_show, foo_store);
/*
* More complex function where we determine which variable is being accessed by
* looking at the attribute for the "baz" and "bar" files.
*/
static ssize_t b_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
{
int var;
if (strcmp(attr->attr.name, "baz") == 0)
var = baz;
else
var = bar;
return sysfs_emit(buf, "%d\n", var);
}
static ssize_t b_store(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t count)
{
int var, ret;
ret = kstrtoint(buf, 10, &var);
if (ret < 0)
return ret;
if (strcmp(attr->attr.name, "baz") == 0)
baz = var;
else
bar = var;
return count;
}
static struct kobj_attribute baz_attribute =
__ATTR(baz, 0664, b_show, b_store);
static struct kobj_attribute bar_attribute =
__ATTR(bar, 0664, b_show, b_store);
/*
* Create a group of attributes so that we can create and destroy them all
* at once.
*/
static struct attribute *attrs[] = {
&foo_attribute.attr,
&baz_attribute.attr,
&bar_attribute.attr,
NULL, /* need to NULL terminate the list of attributes */
};
/*
* An unnamed attribute group will put all of the attributes directly in
* the kobject directory. If we specify a name, a subdirectory will be
* created for the attributes with the directory being the name of the
* attribute group.
*/
static struct attribute_group attr_group = {
.attrs = attrs,
};
static struct kobject *example_kobj;
static int __init example_init(void)
{
int retval;
/*
* Create a simple kobject with the name of "kobject_example",
* located under /sys/kernel/
*
* As this is a simple directory, no uevent will be sent to
* userspace. That is why this function should not be used for
* any type of dynamic kobjects, where the name and number are
* not known ahead of time.
*/
example_kobj = kobject_create_and_add("kobject_example", kernel_kobj);
if (!example_kobj)
return -ENOMEM;
/* Create the files associated with this kobject */
retval = sysfs_create_group(example_kobj, &attr_group);
if (retval)
kobject_put(example_kobj);
return retval;
}
static void __exit example_exit(void)
{
kobject_put(example_kobj);
}
module_init(example_init);
module_exit(example_exit);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Greg Kroah-Hartman <greg@kroah.com>");
9.2.1 对应的Makefile
EXTRA_CFLAGS += $(DEBFLAGS)
#EXTRA_CFLAGS += -I$(INCDIR)
########## change your module name here
MODULE = myKobj
########## change your obj file(s) here
$(MODULE)-objs:= kobject-example.o
#CROSS_COMPILE ?= arm-linux-gnueabihf-
#ARCH ?= arm
ifneq ($(KERNELRELEASE), )
obj-m := $(MODULE).o
else
KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
all:
$(MAKE_BEGIN)
@echo
@if \
$(MAKE) INCDIR=$(PWD)/configs -C $(KERNELDIR) M=$(PWD) modules; \
then $(MAKE_DONE);\
else \
$(MAKE_ERR);\
exit 1; \
fi
endif
show:
@echo "ARCH : ${ARCH}"
@echo "CC : ${CROSS_COMPILE}gcc"
@echo "KDIR : ${KERNELDIR}"
@echo "$(MODULE): $(ALLOBJS)"
clean:
$(CLEAN_BEGIN)
rm -rf *.cmd *.o *.ko *.mod.c *.symvers *.order *.markers .tmp_versions .*.cmd *~ .*.d
$(CLEAN_END)
.PHONY:all clean show
#xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
### nothing
#OFFSET=\e[21G # 21 col
COLOR1=\e[32m # all --> bule
COLOR2=\e[33m # clean --> brown
COLOR3=\e[31m # error --> red
RESET=\e[0m
CLEAN_BEGIN=@echo -e "$(OFFSET)$(COLOR2)Cleaning up...$(RESET)"
CLEAN_END=@echo -e "$(OFFSET)$(COLOR2)Cleaned.$(RESET)"
MAKE_BEGIN=@echo -ne "$(OFFSET)$(COLOR1)Compiling...$(RESET)"
### I do not forget "@", but it DOES NOT need "@"
MAKE_DONE=echo -e "$(OFFSET)$(COLOR1)Compilied.$(RESET)"
MAKE_ERR=echo -e "$(OFFSET)$(COLOR3)[Oops! Error occurred]$(RESET)"
9.2.2 测试
编译以后，加载模块：
sudo insmod myKobj.ko
发现创建了/sys/kernel/kobject_example/目录，而且目录中有3个属性文件。
uos@uos-PC:$ ls /sys/kernel/kobject_example/
bar baz foo
读写这些属性
root@uos-PC:/home/uos/Desktop/samples/kobject# cd
root@uos-PC:~#
root@uos-PC:~# ls /sys/kernel/kobject_example/
bar baz foo
root@uos-PC:~# cat /sys/kernel/kobject_example/bar
0
root@uos-PC:~# cat /sys/kernel/kobject_example/baz
0
root@uos-PC:~# cat /sys/kernel/kobject_example/foo
0
root@uos-PC:~# echo "2021" > /sys/kernel/kobject_example/foo
root@uos-PC:~# cat /sys/kernel/kobject_example/foo
2021
root@uos-PC:~#
9.3 内核kset例子
代码来自：samples/kobject/kset-example.c。
可能会遇到error: negative width in bit-field ‘’这个错误，需要将__ATTR中的666权限改为664。
// SPDX-License-Identifier: GPL-2.0
/*
* Sample kset and ktype implementation
*
* Copyright (C) 2004-2007 Greg Kroah-Hartman <greg@kroah.com>
* Copyright (C) 2007 Novell Inc.
*/
#include <linux/kobject.h>
#include <linux/string.h>
#include <linux/sysfs.h>
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/init.h>
/*
* This module shows how to create a kset in sysfs called
* /sys/kernel/kset-example
* Then tree kobjects are created and assigned to this kset, "foo", "baz",
* and "bar". In those kobjects, attributes of the same name are also
* created and if an integer is written to these files, it can be later
* read out of it.
*/
/*
* This is our "object" that we will create a few of and register them with
* sysfs.
*/
struct foo_obj {
struct kobject kobj;
int foo;
int baz;
int bar;
};
#define to_foo_obj(x) container_of(x, struct foo_obj, kobj)
/* a custom attribute that works just for a struct foo_obj. */
struct foo_attribute {
struct attribute attr;
ssize_t (*show)(struct foo_obj *foo, struct foo_attribute *attr, char *buf);
ssize_t (*store)(struct foo_obj *foo, struct foo_attribute *attr, const char *buf, size_t count);
};
#define to_foo_attr(x) container_of(x, struct foo_attribute, attr)
/*
* The default show function that must be passed to sysfs. This will be
* called by sysfs for whenever a show function is called by the user on a
* sysfs file associated with the kobjects we have registered. We need to
* transpose back from a "default" kobject to our custom struct foo_obj and
* then call the show function for that specific object.
*/
static ssize_t foo_attr_show(struct kobject *kobj,
struct attribute *attr,
char *buf)
{
struct foo_attribute *attribute;
struct foo_obj *foo;
attribute = to_foo_attr(attr);
foo = to_foo_obj(kobj);
if (!attribute->show)
return -EIO;
return attribute->show(foo, attribute, buf);
}
/*
* Just like the default show function above, but this one is for when the
* sysfs "store" is requested (when a value is written to a file.)
*/
static ssize_t foo_attr_store(struct kobject *kobj,
struct attribute *attr,
const char *buf, size_t len)
{
struct foo_attribute *attribute;
struct foo_obj *foo;
attribute = to_foo_attr(attr);
foo = to_foo_obj(kobj);
if (!attribute->store)
return -EIO;
return attribute->store(foo, attribute, buf, len);
}
/* Our custom sysfs_ops that we will associate with our ktype later on */
static const struct sysfs_ops foo_sysfs_ops = {
.show = foo_attr_show,
.store = foo_attr_store,
};
/*
* The release function for our object. This is REQUIRED by the kernel to
* have. We free the memory held in our object here.
*
* NEVER try to get away with just a "blank" release function to try to be
* smarter than the kernel. Turns out, no one ever is...
*/
static void foo_release(struct kobject *kobj)
{
struct foo_obj *foo;
foo = to_foo_obj(kobj);
kfree(foo);
}
/*
* The "foo" file where the .foo variable is read from and written to.
*/
static ssize_t foo_show(struct foo_obj *foo_obj, struct foo_attribute *attr,
char *buf)
{
return sysfs_emit(buf, "%d\n", foo_obj->foo);
}
static ssize_t foo_store(struct foo_obj *foo_obj, struct foo_attribute *attr,
const char *buf, size_t count)
{
int ret;
ret = kstrtoint(buf, 10, &foo_obj->foo);
if (ret < 0)
return ret;
return count;
}
/* Sysfs attributes cannot be world-writable. */
static struct foo_attribute foo_attribute =
__ATTR(foo, 0664, foo_show, foo_store);
/*
* More complex function where we determine which variable is being accessed by
* looking at the attribute for the "baz" and "bar" files.
*/
static ssize_t b_show(struct foo_obj *foo_obj, struct foo_attribute *attr,
char *buf)
{
int var;
if (strcmp(attr->attr.name, "baz") == 0)
var = foo_obj->baz;
else
var = foo_obj->bar;
return sysfs_emit(buf, "%d\n", var);
}
static ssize_t b_store(struct foo_obj *foo_obj, struct foo_attribute *attr,
const char *buf, size_t count)
{
int var, ret;
ret = kstrtoint(buf, 10, &var);
if (ret < 0)
return ret;
if (strcmp(attr->attr.name, "baz") == 0)
foo_obj->baz = var;
else
foo_obj->bar = var;
return count;
}
static struct foo_attribute baz_attribute =
__ATTR(baz, 0664, b_show, b_store);
static struct foo_attribute bar_attribute =
__ATTR(bar, 0664, b_show, b_store);
/*
* Create a group of attributes so that we can create and destroy them all
* at once.
*/
static struct attribute *foo_default_attrs[] = {
&foo_attribute.attr,
&baz_attribute.attr,
&bar_attribute.attr,
NULL, /* need to NULL terminate the list of attributes */
};
ATTRIBUTE_GROUPS(foo_default);
/*
* Our own ktype for our kobjects. Here we specify our sysfs ops, the
* release function, and the set of default attributes we want created
* whenever a kobject of this type is registered with the kernel.
*/
static struct kobj_type foo_ktype = {
.sysfs_ops = &foo_sysfs_ops,
.release = foo_release,
.default_groups = foo_default_groups,
};
static struct kset *example_kset;
static struct foo_obj *foo_obj;
static struct foo_obj *bar_obj;
static struct foo_obj *baz_obj;
static struct foo_obj *create_foo_obj(const char *name)
{
struct foo_obj *foo;
int retval;
/* allocate the memory for the whole object */
foo = kzalloc(sizeof(*foo), GFP_KERNEL);
if (!foo)
return NULL;
/*
* As we have a kset for this kobject, we need to set it before calling
* the kobject core.
*/
foo->kobj.kset = example_kset;
/*
* Initialize and add the kobject to the kernel. All the default files
* will be created here. As we have already specified a kset for this
* kobject, we don't have to set a parent for the kobject, the kobject
* will be placed beneath that kset automatically.
*/
retval = kobject_init_and_add(&foo->kobj, &foo_ktype, NULL, "%s", name);
if (retval) {
kobject_put(&foo->kobj);
return NULL;
}
/*
* We are always responsible for sending the uevent that the kobject
* was added to the system.
*/
kobject_uevent(&foo->kobj, KOBJ_ADD);
return foo;
}
static void destroy_foo_obj(struct foo_obj *foo)
{
kobject_put(&foo->kobj);
}
static int __init example_init(void)
{
/*
* Create a kset with the name of "kset_example",
* located under /sys/kernel/
*/
example_kset = kset_create_and_add("kset_example", NULL, kernel_kobj);
if (!example_kset)
return -ENOMEM;
/*
* Create three objects and register them with our kset
*/
foo_obj = create_foo_obj("foo");
if (!foo_obj)
goto foo_error;
bar_obj = create_foo_obj("bar");
if (!bar_obj)
goto bar_error;
baz_obj = create_foo_obj("baz");
if (!baz_obj)
goto baz_error;
return 0;
baz_error:
destroy_foo_obj(bar_obj);
bar_error:
destroy_foo_obj(foo_obj);
foo_error:
kset_unregister(example_kset);
return -EINVAL;
}
static void __exit example_exit(void)
{
destroy_foo_obj(baz_obj);
destroy_foo_obj(bar_obj);
destroy_foo_obj(foo_obj);
kset_unregister(example_kset);
}
module_init(example_init);
module_exit(example_exit);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Greg Kroah-Hartman <greg@kroah.com>");
9.3.1 对应的Makefile
EXTRA_CFLAGS += $(DEBFLAGS)
#EXTRA_CFLAGS += -I$(INCDIR)
########## change your module name here
MODULE = myKset
########## change your obj file(s) here
#$(MODULE)-objs:= kobject-example.o
$(MODULE)-objs:= kset-example.o
#CROSS_COMPILE ?= arm-linux-gnueabihf-
#ARCH ?= arm
ifneq ($(KERNELRELEASE), )
obj-m := $(MODULE).o
else
KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
all:
$(MAKE_BEGIN)
@echo
@if \
$(MAKE) INCDIR=$(PWD)/configs -C $(KERNELDIR) M=$(PWD) modules; \
then $(MAKE_DONE);\
else \
$(MAKE_ERR);\
exit 1; \
fi
endif
show:
@echo "ARCH : ${ARCH}"
@echo "CC : ${CROSS_COMPILE}gcc"
@echo "KDIR : ${KERNELDIR}"
@echo "$(MODULE): $(ALLOBJS)"
clean:
$(CLEAN_BEGIN)
rm -rf *.cmd *.o *.ko *.mod.c *.symvers *.order *.markers .tmp_versions .*.cmd *~ .*.d
$(CLEAN_END)
.PHONY:all clean show
#xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
### nothing
#OFFSET=\e[21G # 21 col
COLOR1=\e[32m # all --> bule
COLOR2=\e[33m # clean --> brown
COLOR3=\e[31m # error --> red
RESET=\e[0m
CLEAN_BEGIN=@echo -e "$(OFFSET)$(COLOR2)Cleaning up...$(RESET)"
CLEAN_END=@echo -e "$(OFFSET)$(COLOR2)Cleaned.$(RESET)"
MAKE_BEGIN=@echo -ne "$(OFFSET)$(COLOR1)Compiling...$(RESET)"
### I do not forget "@", but it DOES NOT need "@"
MAKE_DONE=echo -e "$(OFFSET)$(COLOR1)Compilied.$(RESET)"
MAKE_ERR=echo -e "$(OFFSET)$(COLOR3)[Oops! Error occurred]$(RESET)"
9.3.2 测试
编译以后，加载模块：
sudo insmod myKset.ko
发现创建了/sys/kernel/kset_example/目录，而且目录中有3个子目录，每一个子目录中都有3个属性文件。
root@uos-PC:~# tree /sys/kernel/kset_example/
/sys/kernel/kset_example/
├── bar
│ ├── bar
│ ├── baz
│ └── foo
├── baz
│ ├── bar
│ ├── baz
│ └── foo
└── foo
├── bar
├── baz
└── foo
3 directories, 9 files
10. 附录：一部分关于kobject的API
10.1 动态创建
struct kobject *kobject_create(void);
动态创建一个kobject结构，并将其设置为一个带默认释放方法（dynamic_kobj_ktype）的动态的kobject。
如果无法创建kobject，将会返回NULL。从这里返回的kobject 结构释放必须调用kobject_put() 方法而不是kfree()，因为kobject_init()已经被调用过了。
10.2 初始化
创建kobject当然必须初始化kobject对象，kobject的一些内部成员需要(强制)通过kobject_init()初始化：
void kobject_init(struct kobject *kobj, struct kobj_type *ktype);
该方法会正确的初始化一个kobject来保证它可以被传递给kobject_add()
该功能被调用后，kobject必须通过调用kobject_put()来清理，而不是直接调用kfree，来保证所有的内存都可以被正确的清理。
辅助函数kobject_init_and_add用来在同时初始化和添加kobject，它的参数和前面介绍的单独使用kobject_init()、kobject_add()这两个函数时一样
int kobject_init_and_add(struct kobject *kobj, struct kobj_type *ktype,
struct kobject *parent, const char *fmt, ...);
10.3 添加到sysfs
在调用kobject_init将kobject注册到sysfs之后，必须调用kobject_add()添加:
/**
* kobject_add - kobject添加主方法
* @kobj: 要添加的kobject
* @parent: 指向父kobject的指针
* @fmt: kobject带的名称格式
*
* 本方法中会设置kobject名称并添加到kobject阶层。
*
* 如果设置了@parent, 那么@kobj的parent将会被设置为它.
* 如果 @parent为空, 那么该@kobj的 parent会被设置为与该kobject
* 相关联的. 如果没有kset分配给这个kobject，那么该kobject会放在
* sysfs的根目录。
*
* 如果该方法返回错误，必须调用 kobject_put()来正确的清理该object
* 相关联的内存。
* 在任何情况下都不要直接通过调用to kfree()来直接释放传递给该方法
* 的kobject，那样会导致内存泄露。
*
* 注意，该调用不会创建"add" uevent, 调用方需要为该object设置好所有
* 必要的sysfs文件，然后再调用带UEVENT_ADD 参数的kobject_uevent()
* 来保证用户控件可以正确的收到该kobject创建的通知。
*/
int kobject_add(struct kobject *kobj, struct kobject *parent, const char *fmt, ...);
它正确设置了kobject的名称和父节点，如果这个kobject和一个特定的kset关联，则kobj->kset必须在调用kobject_add之前被指定。
若kobject已经跟一个kset关联，在调用kobject_add时可以将这个kobject的父节点设置为NULL，这样它的父节点就会被设置为这个kset本身。
在将kobject添加到kernel时，它的名称就已经被设定好了，代码中不应该直接操作kobject的名称。
不过不需要调用kobject_init()和kobject_add()，因为系统提供了函数kobject_create_and_add()。
当kobj，无parent、无kset时，将在sysfs的根目录(即/sys/)下创建目录；
当kobj，无parent、有kset时，kobject_add()会设置kobj->parent为kset->kobj；因此会在该kset下创建目录；该kobj会加入kset.list；同时，会对kobj->kset->kobj增加两次引用：1.增加对kobj->parent的引用；2.增加对kobj->kset的引用。
当kobj，有parent、无kset时，kobject_add()会在该parent下创建目录；同时，会对parent增加引用。
当kobj，有parent、有kset时，优先在parent下创建目录；该kobj会加入kset.list；同时，会分别对parent、kset增加引用计数。
#include <linux/kobject.h>
#if 0 // 下面两种操作等价
struct kobject *kobject_create(void);
int kobject_add(struct kobject *kobj);
#else
struct kobject *kobject_create_and_add(const char *name, struct kobject *parent);
// 再也没有 kobject_register 这个函数了
#endif
10.4 创建简单的kobject
有些时候，开发者希望的只是在sysfs中创建一个目录，并且不会被kset、show、store函数等细节的复杂概念所迷惑。
这里有一个可以单独创建kobject的例外，为了创建这样一个入口，可以通过如下的函数来实现：
struct kobject *kobject_create_and_add(char *name, struct kobject *parent);
这个函数会创建一个kobject，并把它的目录放到指定父节点在sysfs中目录里面。
10.5 重命名
如果你必须为kobject改名，则调用kobject_rename()函数实现:
int kobject_rename(struct kobject *kobj, const char *new_name);
// 如果 kobject 还没被 add 进 sysfs，
// 那么还可以使用下列的函数，否则必须使用kobject_rename
int kobject_set_name(struct kobject *kobj, const char *fmt, ...);
int kobject_set_name_vargs(struct kobject *kobj, const char *fmt,
va_list vargs);
kobject_rename内部并不执行任何锁定操作，也没用何时名称是有效的概念。因此调用者必须自己实现完整性检查和保证序列性。
可以通过kobject_name()函数来正确获取kobject的名称：
const char *kobject_name(const struct kobject * kobj);
11. 小结
kobj对应一个目录；kobj实现对象的生命周期管理（计数为0即清除）；kset包含一个kobj，相当于也是一个目录；kset是一个容器，可以包容不同类型的kobj（甚至父子关系的两个kobj都可以属于一个kset）；- 注册
kobj（如kobj_add()函数）时，优先以kobj->parent作为自身的parent目录；
其次，以kset作为parent目录；若都没有，则是sysfs的顶层目录；
同时，若设置了kset，还会将kobj加入kset.list。举例：
1、无parent、无kset，则将在sysfs的根目录（即/sys/）下创建目录；
2、无parent、有kset，则将在kset下创建目录；并将kobj加入kset.list；
3、有parent、无kset，则将在parent下创建目录；
4、有parent、有kset，则将在parent下创建目录，并将kobj加入kset.list； - 注册
kset时，如果它的kobj->parent为空，则设置它所属的kset（kset.kobj->kset.kobj）为parent，即优先使用kobj所属的parent；然后再使用kset作为parent。（如platform_bus_type的注册，如某些input设备的注册） - 注册
device时，dev->kobj.kset = devices_kset；然而kobj->parent的选取有优先次序：
refer to
242
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
