還記得上篇講到的platform總線、設備、驅動的知識？？這里我們先來看一段documentation/filesystems/sysfs.txt里關於sysfs文件系統的描述：
sysfs is a ram-based filesystem initially based on ramfs.It provides a means to export kernel data structures,their attributes,and the linkages between them to userspace.
sysfs 文件系統是基於ram文件系統的，
這里注意：
ramdisk 文件系統基於磁盤模擬技術，實際文件系統是ex2 ex3等
sysfs是一種基於ram文件系統，和proc一樣。
Sysfs文件系統是一個類似於proc文件系統的特殊文件系統，用於將系統中的設備組織成層次結構，並向用戶模式程序提供詳細的內核數據結構信息。
其實，就是 在用戶態可以通過對sys文件系統的訪問，來看內核態的一些驅動或者設備等。
好了，下面直接去sys目錄看看吧！！！
localhost:/sys#ls
/sys/ block/ bus/ class/ devices/ firmware/ kernel/ module/ power/
Block目錄：包含所有的塊設備，進入到block目錄下，會發現下面全是link文件，link到sys/device/目錄下的一些設備。
Devices目錄：包含系統所有的設備，並根據設備掛接的總線類型組織成層次結構
Bus目錄：包含系統中所有的總線類型
Drivers目錄：包括內核中所有已注冊的設備驅動程序
Class目錄：系統中的設備類型（如網卡設備，聲卡設備等）。去class目錄中看一下，隨便進到一個文件夾下，會發現該文件夾下的文件其實是連接文件，link到/sys/device/.http://www.cnblogs.com/...下的一個設備文件。 可以說明，其實class目錄並不會新建什么設備，只是將已經注冊的設備，在class目錄下重新歸類，放在一起。
但是，你可能根本沒有去關心過sysfs的掛載過程，她是這樣被掛載的。
mount -t sysfs sysfs /sys
但是sys文件是根據什么依據來創建其內容呢？他的信息來源是什么呢？
下面來分析sys的信息來源。
Linus設備底層模型
Kobject
應該說每個Kobject結構都對應一個 目錄。for example：/sys/bus/pci/drivers/serial/ 路徑， serial這個目錄就是由一個kobject 結構體 來表示的。由此可見，Kobject是用來表示 直接對應着一個 設備，或設備驅動 的目錄。Kobject包含了 這個目錄的一些信息，如：目錄名，父目錄，設備名稱等等一些信息。當然，如果Kobject用來表示一個目錄，那么他所包含的信息是差不多了，但是Kobject表示的目錄是用來描述某一個設備/設備驅動 的。所以僅僅Kobject這個結構體還不能完全的描述這個設備/設備驅動，再所以，Kobject這個結構體不會單獨使用，一般都會包含在另一個結構體中，用網絡上的話說就是包含在一個容器中。這個容器可以是：device結構體，device_drive結構體。現在層次就很明顯了，device/device_drive來表示一個設備/設備驅動，當然包含了這個設備/設備驅動的信息，並且還包含了這個驅動所對應的目錄的信息，Kobject結構。
當然device/device_drive在另外一層的東西了，后面再分析。我們在這里就先分析Kobject結構。
注意：在kenerl中，如kref，前面講到的 page_reference變量。 都用來表示被引用。 所以 以后看變量的時候要注意看 ref或reference，來表示被引用。
相關函數
void kobject_init(struct kobject * kobj)；kobject初始化函數。
int kobject_set_name(struct kobject *kobj, const char *format, ...)；設置指定kobject的名稱。
struct kobject *kobject_get(struct kobject *kobj)；將kobj 對象的引用計數加1，同時返回該對象的指針。
void kobject_put(struct kobject * kobj)； 將kobj對象的引用計數減1，如果引用計數降為0，則調用kobject release()釋放該kobject對象。
int kobject_add(struct kobject * kobj)；將kobj對象加入Linux設備層次。掛接該kobject對象到kset的list鏈中，增加父目錄各級kobject的引用計數，在其parent指向的目錄下創建文件節點，並啟動該類型內核對象的hotplug函數。
int kobject_register(struct kobject * kobj)；kobject注冊函數。通過調用kobject init()初始化kobj，再調用kobject_add()完成該內核對象的注冊。
void kobject_del(struct kobject * kobj)；從Linux設備層次(hierarchy)中刪除kobj對象。
void kobject_unregister(struct kobject * kobj)；kobject注銷函數。與kobject register()相反，它首先調用kobject del從設備層次中刪除該對象，再調用kobject put()減少該對象的引用計數，如果引用計數降為0，則釋放kobject對象。
kobject下的結構體描述：
struct kobj_type
{
void (*release)(struct kobject *);
struct sysfs_ops * sysfs_ops;
struct attribute ** default_attrs;
};
Kobj type數據結構包含三個域：一個release方法用於釋放kobject占用的資源；一個sysfs ops指針指向sysfs操作表和一個sysfs文件系統缺省屬性列表。
Sysfs操作表包括兩個函數store()和show()。當用戶態讀取屬性時，show()函數被調用，該函數編碼指定屬性值存入buffer中返回給用戶態；而store()函數用於存儲用戶態傳入的屬性值。
attribute struct attribute
{
char * name;
struct module * owner;
mode_t mode;
};
attribute屬性。它以文件的形式輸出到sysfs的目錄當中。在kobject對應的目錄下面。文件 名就是name。文件讀寫的方法對應於kobj type中的sysfs ops。
Kset
像剛才所說，每個Kobject結構都對應一個 目錄。for example：/sys/bus/pci/drivers/serial/ 路徑， /serial/這個目錄由一個kobject 結構體 來表示的。但是/serial/的上一級目錄/drivers/如何表示呢？那么就出現了Kset這個結構體。
- /**
- * 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 {
- struct list_head list; //由於Kset下會有很多個Kobject的目錄，所以使用一個list將他們全部link起來。
- spinlock_t list_lock; //鎖機制
- struct kobject kobj; //Kest本質上來說，也是個目錄，所以他也使用了Kobject，來表示他自己的這個目錄
- struct kset_uevent_ops *uevent_ops; //由於Kset是將很多的有公共特性的Kobject集中到一起，所以這個變量操作，在他的目錄下的一些共性操作。
- };
subsystem
在以前的版本中，還有subsystem結構，但 是在現在的版本中都已經去掉了，用Kset來代替
1 struct subsystem {
2 struct kset kset;
3
4 struct rw semaphore rwsem;
5
6 };
由上面聲明可以看出，完全可以讓Kset來代替subsystem結構。
總結：
1，在sys下，表示一個目錄使用的結構體是 Kobject，但是在linux的內核中，有硬件的設備 和 軟件的驅動，在sys下都需要用一個目錄來表示。 單純的一個Kobject結構無法表示完全，增加了容器，來封裝Kobject。 即下面要將的：device和drive_device結構。
2， 最底層驅動目錄的上一層目錄，從sys角度上來說，他依然是個目錄，所以他也有Kobjec這個變量。但是從他的意義上講，他將 一些有公共特性Kobjec 的 device/driver_device結構組織到了一起，所以除了有Kobject這個變量外，他又添加了一些變量，組成了Kset這個結構來表示這一級的目錄。但是僅僅是用Kset來表示了這一級的目錄，和1，一樣，僅僅表示一個目錄是不夠的，在linux內核中，需要他在軟件上有個映射。所以，也將Kset進行了封裝，形成了 bus_type這個結構。
3， 從1 ，2，的解釋可以看出，應為kobject在Kset的目錄下，那么 device/device_driver 就在 bus_type結構下。所以，linux驅動模型中，驅動和設備都是掛在總線下面的。
4， 如上所述，Kset的意義：表示一個目錄（由結構體下的Kobject來完成），並且這個目錄下的所有目錄有共同的特性（所以說，Kset表示的目錄下，不一定非要是Kobject街頭的，也可以是Kset結構的。即：Kset嵌套Kset）。所以使用Kset來代替了以前的 subsystem結構。
貼兩張圖來形象了解一下：
1， Kset和Kobject的連接圖（from linux那些事之我是sys）
2，整個sys目錄的結構體表示圖：（from ULK--當然，在這里subsystem結構要換成Kset了，但我個人認為，以前的subsystem結構上會更清晰，不是嗎？）
（但這邊有個問題。。。Kobject通過下面的attribute來建立目錄下的文件，但我看到目錄下有好幾個文件，難道是根據一個attribute來建立好幾個文件？疑惑ing，好像attribute是個指針，還能當數組首地址？bus_add_attrs函數中如是說）
設備模型的上層容器
剛才講了Kset和Kobject結構體，都是用來表示 sys下的目錄結構的。下面來講驅動中封裝這些結構的容器。
總線bus
bus_type結構： 剛才上面已經將的夠多的了，閑話少說，直接上code。
1 struct bus_type {
2 const char *name; //總線的名稱，這個名字理論上並不是sys/bus/下的那些目錄的目錄名。那些目錄的目錄名應該是在下面變量 subsys_private p.sbusys的name變量中。但是往往那個name是由這個name賦值的，所以就一樣的。但這里要明白的是（還是上面的老生常談），表示目錄是由Kset.Kobject這個東西來表示的。
3 struct bus_attribute *bus_attrs; //根據后面的bus_add_attrs函數分析，這些個屬性可能是數組
4 struct device_attribute *dev_attrs;
5 struct driver_attribute *drv_attrs; //bus device driver的屬性，一些操作導入導出的屬性，等后面再分析。
6
7 int (*match)(struct device *dev, struct device_driver *drv);
8 int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
9 int (*probe)(struct device *dev);
10 int (*remove)(struct device *dev);
11 void (*shutdown)(struct device *dev);
12
13 int (*suspend)(struct device *dev, pm_message_t state);
14 int (*resume)(struct device *dev); //總線的操作
15
16 const struct dev_pm_ops *pm; //power manage 的operations
17
18 struct subsys_private *p; 見下面：
19 };
1 struct subsys_private { //為了保持和上面的代碼的連貫，我將這個結構體的注釋部分放到下面了。注釋還是比較清楚的，不解釋
2 struct kset subsys;
3 struct kset *devices_kset;</p><p> struct kset *drivers_kset;
4 struct klist klist_devices;
5 struct klist klist_drivers;
6 struct blocking_notifier_head bus_notifier;
7 unsigned int drivers_autoprobe:1;
8 struct bus_type *bus;</p><p> struct list_head class_interfaces;
9 struct kset glue_dirs;
10 struct mutex class_mutex;
11 struct class *class;
12 };
13 * struct subsys_private - structure to hold the private to the driver core portions of the bus_type/class structure.
14 *
15 * @subsys - the struct kset that defines this subsystem
16 * @devices_kset - the list of devices associated
17 *
18 * @drivers_kset - the list of drivers associated
19 * @klist_devices - the klist to iterate over the @devices_kset
20 * @klist_drivers - the klist to iterate over the @drivers_kset
21 * @bus_notifier - the bus notifier list for anything that cares about things
22 * on this bus.
23 * @bus - pointer back to the struct bus_type that this structure is associated
24 * with.
25 *
26 * @class_interfaces - list of class_interfaces associated
27 * @glue_dirs - "glue" directory to put in-between the parent device to
28 * avoid namespace conflicts
29 * @class_mutex - mutex to protect the children, devices, and interfaces lists.
30 * @class - pointer back to the struct class that this structure is associated
31 * with.
32 *
33 * This structure is the one that is the actual kobject allowing struct
34 * bus_type/class to be statically allocated safely. Nothing outside of the
35 * driver core should ever touch these fields.
36 */</p>
這個結構體用來描述比如：/sys/bus/pci pci總線，/sys/bus/platform platform總線等。
另外：從這個結構體分析下來，整個bus的目錄結構都很清楚了eg：
1，可以找到總線下的設備目錄： bus_type bus ---> subsys_private p---->Kest devices_kset
2，可以找到總線下的設備驅動目錄： bus_type bus ---> subsys_private p---->Kest driver_kset
另外，找到的也只是目錄，因為找到的僅僅是Kset結構。
設備device
首先明白，device這個結構並不是直接掛在bus下的，可以到/sys/bus/platform/device下隨便看一下，發現里面的都是link文件，link到/sys/device/下。所以真正的device結構體的在/sys/device下的。
- struct device {
- struct device *parent; //設備的父設備指針，那么就是說device的目錄也是可以嵌套的？到/sys/device/platform/serial8250目錄下看看，竟然還存在着 tty/ 目錄，是不是這樣嵌套的呢？？天知道。。。。。
- struct device_private *p;
- struct kobject kobj; //這個就是說了好久的 Kobject
- const char *init_name; /* initial name of the device */
- struct device_type *type;
- struct mutex mutex; /* mutex to synchronize calls to
- * its driver.
- */
- struct bus_type *bus; /* type of bus device is on *///他所在的總線的類型
- struct device_driver *driver; /* which driver has allocated this //支持的驅動
- device */
- void *platform_data; /* Platform specific data, device
- core doesn't touch it */
- struct dev_pm_info power;
- struct dev_power_domain *pwr_domain;
- #ifdef CONFIG_NUMA
- int numa_node; /* NUMA node this device is close to */
- #endif
- u64 *dma_mask; /* dma mask (if dma'able device) */
- u64 coherent_dma_mask;/* Like dma_mask, but for
- alloc_coherent mappings as
- not all hardware supports
- 64 bit addresses for consistent
- allocations such descriptors. */
- struct device_dma_parameters *dma_parms;
- struct list_head dma_pools; /* dma pools (if dma'ble) */
- struct dma_coherent_mem *dma_mem; /* internal for coherent mem
- override */
- /* arch specific additions */
- struct dev_archdata archdata;
- struct device_node *of_node; /* associated device tree node */
- dev_t devt; /* dev_t, creates the sysfs "dev" */
- spinlock_t devres_lock;
- struct list_head devres_head;
- struct klist_node knode_class;
- struct class *class;
- const struct attribute_group **groups; /* optional groups */
- void (*release)(struct device *dev);
- };
設備driver
- struct device_driver {
- const char *name;
- struct bus_type *bus;
- struct module *owner;
- const char *mod_name; /* used for built-in modules */
- bool suppress_bind_attrs; /* disables bind/unbind via sysfs */
- const struct of_device_id *of_match_table;
- int (*probe) (struct device *dev);
- int (*remove) (struct device *dev);
- void (*shutdown) (struct device *dev);
- int (*suspend) (struct device *dev, pm_message_t state);
- int (*resume) (struct device *dev);
- const struct attribute_group **groups;
- const struct dev_pm_ops *pm;
- struct driver_private *p;
- };
設備模型的注冊等操作：
總線的操作：
用戶可以自己注冊一個總線，然后將自己喜歡的設備和驅動掛載到下面。但是linux 2.6中，有個默認的總線，platform總線。我們就分析一下這個總線。
小記：隨手在Source insight里敲了個 platform_bus_init，結果的真的有這個函數，再看一下誰調用他了吧？ 竟然是drive_init。啊。。終於找到組織了，在start_kernel的最后一步后調用這個drive_init了。
- int __init platform_bus_init(void)
- {
- int error;
- early_platform_cleanup(); //清除platform總線上的設備？不確定，，，好像就是將early_platform_device_list這個里的內容清空。
- error = device_register(&platform_bus); //設備注冊。哦，linux將platform也當成了一個設備，他在/sys/device目錄下。當然，以后會在platform這個設備下再建立其他的設備，回顧剛才介紹device結構體時候有個parent變量，應該就是用在這里的。具體device_register這個函數，后面再介紹
- if (error)
- return error;
- error = bus_register(&platform_bus_type); //總線的注冊。
- if (error)
- device_unregister(&platform_bus);
- return error;
- }
- * bus_register - register a bus with the system.
- * @bus: bus.
- *
- * Once we have that, we registered the bus with the kobject
- * infrastructure, then register the children subsystems it has:
- * the devices and drivers that belong to the bus.
- */
- int bus_register(struct bus_type *bus)
- {
- int retval;
- struct subsys_private *priv;
- priv = kzalloc(sizeof(struct subsys_private), GFP_KERNEL);
- if (!priv)
- return -ENOMEM;
- priv->bus = bus;
- bus->p = priv;
- BLOCKING_INIT_NOTIFIER_HEAD(&priv->bus_notifier); //bus_notifier就是個讀寫信號量，和RCU機制，這里進行初始化
- retval = kobject_set_name(&priv->subsys.kobj, "%s", bus->name); //設置name，這個name會顯示在sys/bus/下
- if (retval)
- goto out;
- priv->subsys.kobj.kset = bus_kset;
- priv->subsys.kobj.ktype = &bus_ktype;
- priv->drivers_autoprobe = 1;
- retval = kset_register(&priv->subsys); //這個應該是注冊bus，但看函數名是ket_register，所以可能會根據剛才對subsys.kobj.kset的賦值來判定是bus，並注冊。后面分析。
- if (retval)
- goto out;
- retval = bus_create_file(bus, &bus_attr_uevent); //在對應的bus目錄下，根據attribute來創建一個文件
- if (retval)
- goto bus_uevent_fail;
- priv->devices_kset = kset_create_and_add("devices", NULL, //這就函數應該是創建目錄，所以在每個bus下會有 device和driver 兩個目錄。
- &priv->subsys.kobj);
- if (!priv->devices_kset) {
- retval = -ENOMEM;
- goto bus_devices_fail;
- }
- priv->drivers_kset = kset_create_and_add("drivers", NULL,
- &priv->subsys.kobj);
- if (!priv->drivers_kset) {
- retval = -ENOMEM;
- goto bus_drivers_fail;
- }
- klist_init(&priv->klist_devices, klist_devices_get, klist_devices_put);
- klist_init(&priv->klist_drivers, NULL, NULL); //klist還是沒搞明白怎么用，以后再說吧
- retval = add_probe_files(bus); //這個也是在對應的總線目錄下，建立bus_attr_drivers_probe 和 bus_attr_drivers_autoprobe文件。應該是probe的時候使用。
- if (retval)
- goto bus_probe_files_fail;
- retval = bus_add_attrs(bus); //循環將所有的bus的屬性都建立成一個文件。
- if (retval)
- goto bus_attrs_fail;
- pr_debug("bus: '%s': registered\n", bus->name);
- return 0;
- bus_attrs_fail:
- remove_probe_files(bus);
- bus_probe_files_fail:
- kset_unregister(bus->p->drivers_kset);
- bus_drivers_fail:
- kset_unregister(bus->p->devices_kset);
- bus_devices_fail:
- bus_remove_file(bus, &bus_attr_uevent);
- bus_uevent_fail:
- kset_unregister(&bus->p->subsys);
- out:
- kfree(bus->p);
- bus->p = NULL;
- return retval;
- }
/**
kset_register - initialize and add a kset.
- * @k: kset.
- */
- int kset_register(struct kset *k)
- {
- int err;
- if (!k)
- return -EINVAL;
- kset_init(k); //初始化，沒什么東西
- err = kobject_add_internal(&k->kobj); //下面分析
- if (err)
- return err;
- kobject_uevent(&k->kobj, KOBJ_ADD); //通過這個函數的注釋可知，向usrspace發送信號。
- return 0;
- }
- static int kobject_add_internal(struct kobject *kobj)
- {
- int error = 0;
- struct kobject *parent;</p><p> if (!kobj)
- return -ENOENT;</p><p> if (!kobj->name || !kobj->name[0]) {
- WARN(1, "kobject: (%p): attempted to be registered with empty "
- "name!\n", kobj);
- return -EINVAL;
- }
- parent = kobject_get(kobj->parent);</p><p> /* join kset if set, use it as parent if we do not already have one */
- if (kobj->kset) {
- if (!parent)
- parent = kobject_get(&kobj->kset->kobj); //get kobject->kset, 判斷與parent對比。
- obj_kset_join(kobj); //這個函數，是將kobject的entry這個變量 添加到 他的 上一級的kset結構的 list中。
- 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>");</p><p> error = create_dir(kobj); //創建目錄。比如：/sys/bus 下的 platform， pci等目錄。
- if (error) {
- kobj_kset_leave(kobj);
- kobject_put(parent);
- kobj->parent = NULL;</p><p> /* be noisy on error issues */
- if (error == -EEXIST)
- printk(KERN_ERR "%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
- printk(KERN_ERR "%s failed for %s (%d)\n",
- __func__, kobject_name(kobj), error);
- dump_stack();
- } else
- kobj->state_in_sysfs = 1;</p><p> return error;
- }</p>
到此，bus_register解釋完成。
- * device_register - register a device with the system.
- * @dev: pointer to the device structure
- *
- * This happens in two clean steps - initialize the device
- * and add it to the system. The two steps can be called
- * separately, but this is the easiest and most common.
- * I.e. you should only call the two helpers separately if
- * have a clearly defined need to use and refcount the device
- * before it is added to the hierarchy.
- *
- * NOTE: _Never_ directly free @dev after calling this function, even
- * if it returned an error! Always use put_device() to give up the
- * reference initialized in this function instead.
- */
- int device_register(struct device *dev)
- {
- device_initialize(dev);
- return device_add(dev);
- }
- * device_initialize - init device structure.
- * @dev: device.
- *
- * This prepares the device for use by other layers by initializing
- * its fields.
- * It is the first half of device_register(), if called by
- * that function, though it can also be called separately, so one
- * may use @dev's fields. In particular, get_device()/put_device()
- * may be used for reference counting of @dev after calling this
- * function.
- *
- * NOTE: Use put_device() to give up your reference instead of freeing
- * @dev directly once you have called this function.
- */
- void device_initialize(struct device *dev)
- {
- dev->kobj.kset = devices_kset;
- kobject_init(&dev->kobj, &device_ktype);
- INIT_LIST_HEAD(&dev->dma_pools);
- mutex_init(&dev->mutex);
- lockdep_set_novalidate_class(&dev->mutex);
- spin_lock_init(&dev->devres_lock);
- INIT_LIST_HEAD(&dev->devres_head);
- device_pm_init(dev);
- set_dev_node(dev, -1);
- }
dev_initialize，不解釋。
這里有個疑問：在bus_register的時候，有條語句：priv->subsys.kobj.kset = bus_kset;。在dev_initialize的時候也有條dev->kobj.kset = devices_kset;語句。 剛才以為是上級目錄的kset結構。但是如此看來好像不是很對，因為dev的上級目錄是不定的，可能在/sys/device/platform下，也可能在其他。但是都賦值成devices_kset顯然不對。 那么有可能在一個標志。所有的bus的subsys.kobj.kset 這個變量都是bus_kset， 所有dev->kobj.kset的變量都是devices_kset。具體為什么？
天空中深沉的傳來一句話：1+1=幾？
我說：2
啪，一道雷劈死我了。答曰：你知道的太多了。 為了留條命，就不解釋了。
- /**
- * device_add - add device to device hierarchy.
- * @dev: device.
- *
- * This is part 2 of device_register(), though may be called
- * separately _iff_ device_initialize() has been called separately.
- *
- * This adds @dev to the kobject hierarchy via kobject_add(), adds it
- * to the global and sibling lists for the device, then
- * adds it to the other relevant subsystems of the driver model.
- *
- * NOTE: _Never_ directly free @dev after calling this function, even
- * if it returned an error! Always use put_device() to give up your
- * reference instead.
- */
- int device_add(struct device *dev)
- {
- struct device *parent = NULL;
- struct class_interface *class_intf;
- int error = -EINVAL;
- dev = get_device(dev);
- if (!dev)
- goto done;
- if (!dev->p) {
- error = device_private_init(dev);
- if (error)
- goto done;
- }
- /*
- * for statically allocated devices, which should all be converted
- * some day, we need to initialize the name. We prevent reading back
- * the name, and force the use of dev_name()
- */
- if (dev->init_name) {
- dev_set_name(dev, "%s", dev->init_name);
- dev->init_name = NULL;
- }
- if (!dev_name(dev)) {
- error = -EINVAL;
- goto name_error;
- }
- pr_debug("device: '%s': %s\n", dev_name(dev), __func__);
- parent = get_device(dev->parent);
- setup_parent(dev, parent);
- /* use parent numa_node */
- if (parent)
- set_dev_node(dev, dev_to_node(parent));
- //以上是對device進行初始化，包括name，private，parent……
- /* first, register with generic layer. */
- /* we require the name to be set before, and pass NULL */
- error = kobject_add(&dev->kobj, dev->kobj.parent, NULL); //device添加，根據他的parent等，當然還會根據他的attribute built一些文件。
- if (error)
- goto Error;
- /* notify platform of device entry */
- if (platform_notify)
- platform_notify(dev);
- error = device_create_file(dev, &uevent_attr); //built attr file
- if (error)
- goto attrError;
- if (MAJOR(dev->devt)) {
- error = device_create_file(dev, &devt_attr);
- if (error)
- goto ueventattrError;
- error = device_create_sys_dev_entry(dev);
- if (error)
- goto devtattrError;
- devtmpfs_create_node(dev);
- }
- error = device_add_class_symlinks(dev); //在其他文件夾 建立link文件，這就是為什么在class目錄下也能看到device的目錄和文件了
- if (error)
- goto SymlinkError;
- error = device_add_attrs(dev);
- if (error)
- goto AttrsError;
- error = bus_add_device(dev); //在bus目錄下 建立link文件，所以在/sys/bus/platform/device下回看到n多個link文件。
- if (error)
- goto BusError;
- error = dpm_sysfs_add(dev);
- if (error)
- goto DPMError;
- device_pm_add(dev);
- /* Notify clients of device addition. This call must come
- * after dpm_sysf_add() and before kobject_uevent().
- */
- if (dev->bus)
- blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
- BUS_NOTIFY_ADD_DEVICE, dev);
- kobject_uevent(&dev->kobj, KOBJ_ADD);
- bus_probe_device(dev); //進行probe，看有沒和device相對應的driver文件。
- if (parent)
- klist_add_tail(&dev->p->knode_parent,
- &parent->p->klist_children);
- if (dev->class) {
- mutex_lock(&dev->class->p->class_mutex);
- /* tie the class to the device */
- klist_add_tail(&dev->knode_class,
- &dev->class->p->klist_devices);
- /* notify any interfaces that the device is here */
- list_for_each_entry(class_intf,
- &dev->class->p->class_interfaces, node)
- if (class_intf->add_dev)
- class_intf->add_dev(dev, class_intf);
- mutex_unlock(&dev->class->p->class_mutex);
- }
- done:
- put_device(dev);
- return error;
- DPMError:
- bus_remove_device(dev);
- BusError:
- device_remove_attrs(dev);
- AttrsError:
- device_remove_class_symlinks(dev);
- SymlinkError:
- if (MAJOR(dev->devt))
- devtmpfs_delete_node(dev);
- if (MAJOR(dev->devt))
- device_remove_sys_dev_entry(dev);
- devtattrError:
- if (MAJOR(dev->devt))
- device_remove_file(dev, &devt_attr);
- ueventattrError:
- device_remove_file(dev, &uevent_attr);
- attrError:
- kobject_uevent(&dev->kobj, KOBJ_REMOVE);
- kobject_del(&dev->kobj);
- Error:
- cleanup_device_parent(dev);
- if (parent)
- put_device(parent);
- name_error:
- kfree(dev->p);
- dev->p = NULL;
- goto done;
- }
當然還有 drive_register的函數，其實和device_register差不多，另外，driver_register也會在最后進行probe，看有沒有相應的設備。driver_register會先check這個drvier所在的bus上有沒有probe函數，如果有就運行這個函數進行probe，如果沒有，就運行自己的probe進行probe，這就是我們在驅動中經常看到的probe函數。
所以，在驅動中，先運行drive_register和先運行device_register都是一樣的。
到這里，我們看完了platform總線如何對底層的kobject的封裝機制了吧？？？親們是否明白了呢？？？呵呵，下面的驅動內容會介紹不同的封裝類型，請注意面向對象的思想。