數據結構

2.1 kobject

• kobject代表內核對象，結構體本身不單獨使用，而是嵌套在其他高層結構中，用于組織成拓撲關系；
• sysfs文件系統中一個目錄對應一個kobject；

看看結構體吧：

struct kobject {
	const char		*name;                  /* 名字，對應sysfs下的一個目錄 */
	struct list_head	entry;               /* kobject中插入的 list_head結構，用于構造雙向鏈表 */
	struct kobject		*parent;            /* 指向當前kobject父對象的指針，體現在sys中就是包含當前kobject對象的目錄對象 */
	struct kset		*kset;                    /* 當前kobject對象所屬的集合 */
	struct kobj_type	*ktype;            /* 當前kobject對象的類型 */
	struct kernfs_node	*sd;              /* VFS文件系統的目錄項，是設備和文件之間的橋梁，sysfs中的符號鏈接是通過kernfs_node內的聯合體實現的 */
	struct kref		kref;                     /* kobject的引用計數，當計數為0時，回調之前注冊的release方法釋放該對象 */
#ifdef CONFIG_DEBUG_KOBJECT_RELEASE
	struct delayed_work	release;
#endif
	unsigned int state_initialized:1;                /* 初始化標志位，初始化時被置位 */
	unsigned int state_in_sysfs:1;                  /* kobject在sysfs中的狀態，在目錄中創建則為1，否則為0 */
	unsigned int state_add_uevent_sent:1;      /* 添加設備的uevent事件是否發送標志，添加設備時向用戶空間發送uevent事件，請求新增設備 */
	unsigned int state_remove_uevent_sent:1;  /* 刪除設備的uevent事件是否發送標志，刪除設備時向用戶空間發送uevent事件，請求卸載設備 */
	unsigned int uevent_suppress:1;              /* 是否忽略上報（不上報uevent） */
};

2.2 kset

• kset是包含多個kobject的集合；
• 如果需要在sysfs的目錄中包含多個子目錄，那需要將它定義成一個kset；
• kset結構體中包含struct kobject字段，可以使用該字段鏈接到更上一層的結構，用于構建更復雜的拓撲結構；
• sysfs中的設備組織結構很大程度上根據kset組織的，/sys/bus目錄就是一個kset對象，在Linux設備模型中，注冊設備或驅動時就將kobject添加到對應的kset中；

struct kset {
	struct list_head list;        /* 包含在kset內的所有kobject構成一個雙向鏈表 */
	spinlock_t list_lock;
	struct kobject kobj;       /* 歸屬于該kset的所有的kobject的共有parent */
	const struct kset_uevent_ops *uevent_ops;    /* kset的uevent操作函數集，當kset中的kobject有狀態變化時，會回調這個函數集，以便kset添加新的環境變量或過濾某些uevent，如果一個kobject不屬于任何kset時，是不允許發送uevent的 */
} __randomize_layout;

2.3 ktype

• kobj_type用于表征kobject的類型，指定了刪除kobject時要調用的函數，kobject結構體中有struct kref字段用于對kobject進行引用計數，當計數值為0時，就會調用kobj_type中的release函數對kobject進行釋放，這個就有點類似于C++中的智能指針了；
• kobj_type指定了通過sysfs顯示或修改有關kobject的信息時要處理的操作，實際是調用show/store函數；

struct kobj_type {
	void (*release)(struct kobject *kobj);     /* 釋放kobject對象的接口，有點類似面向對象中的析構 */
	const struct sysfs_ops *sysfs_ops;        /* 操作kobject的方法集 */
	struct attribute **default_attrs;
	const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj);
	const void *(*namespace)(struct kobject *kobj);
};


struct sysfs_ops {      /* kobject操作函數集 */
	ssize_t	(*show)(struct kobject *, struct attribute *, char *);
	ssize_t	(*store)(struct kobject *, struct attribute *, const char *, size_t);
};


/* 所謂的attribute就是內核空間和用戶空間進行信息交互的一種方法，例如某個driver定義了一個變量，卻希望用戶空間程序可以修改該變量，以控制driver的行為，那么可以將該變量以sysfs attribute的形式開放出來 */
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創建的時候，與ktype的關系，這樣理解起來更順：

• kobject在創建的時候，默認設置kobj_type的值為dynamic_kobj_ktype，通常kobject會嵌入在其他結構中來使用，因此它的初始化跟特定的結構相關，典型的比如struct device和struct device_driver；
• 在/sys文件系統中，通過echo/cat的操作，最終會調用到show/store函數，而這兩個函數的具體實現可以放置到驅動程序中；

2.4 結構關系

為了更形象的說明這幾個結構體的關系，再來一張圖：

• kset既是kobject的集合，本身又是一個kobject，進而可以添加到其他的集合中，從而就可以構建成復雜的拓撲結構，滿足/sys文件夾下的文件組織需求；

如果只看kset/kobject的數據結構組織，可能還是會迷惑，它怎么跟Linux的設備模型相關？這時就不得不提到Linux內核中一個很精妙的存在container_of，它可以通過成員變量的地址來獲取所在結構的地址信息。前文提到過kobject/kset結構本身不會單獨使用，通常都是會嵌套在其他結構中，既然kobjcet/kset能組織成拓撲結構，那么包含它們的結構同樣可以構建這個關系，因為可以通過container_of就可以找到結構體的首地址。

• 結構體A、B、C、D、E同樣可以構建拓撲結構關系；
• struct device和struct device_driver結構體中都包含了struct kobject，而struct bus_type結構體中包含了struct kset結構，這個也就對應到前文提到的設備和驅動都添加到總線上，由總線來負責匹配；