Chinaunix首页 | 论坛 | 博客
  • 博客访问: 576844
  • 博文数量: 143
  • 博客积分: 455
  • 博客等级: 一等列兵
  • 技术积分: 861
  • 用 户 组: 普通用户
  • 注册时间: 2012-08-03 00:11
文章分类

全部博文(143)

文章存档

2018年(10)

2017年(6)

2016年(28)

2015年(14)

2014年(67)

2013年(1)

2012年(17)

我的朋友

分类: LINUX

2014-09-03 17:49:36

转载自:http://www.cnblogs.com/myblesh/articles/2367613.html
还记得上篇讲到的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这个结构体。

  1. /** 
  2.  * struct kset - a set of kobjects of a specific type, belonging to a specific subsystem. 
  3.  * 
  4.  * A kset defines a group of kobjects.  They can be individually 
  5.  * different "types" but overall these kobjects all want to be grouped 
  6.  * together and operated on in the same manner.  ksets are used to 
  7.  * define the attribute callbacks and other common events that happen to 
  8.  * a kobject. 
  9.  * 
  10.  * @list: the list of all kobjects for this kset 
  11.  * @list_lock: a lock for iterating over the kobjects 
  12.  * @kobj: the embedded kobject for this kset (recursion, isn't it fun...) 
  13.  * @uevent_ops: the set of uevent operations for this kset.  These are 
  14.  * called whenever a kobject has something happen to it so that the kset 
  15.  * can add new environment variables, or filter out the uevents if so 
  16.  * desired. 
  17.  */  
  18. struct kset {  
  19.     struct list_head list;  //由于Kset下会有很多个Kobject的目录,所以使用一个list将他们全部link起来。  
  20.     spinlock_t list_lock;   //锁机制  
  21.     struct kobject kobj;    //Kest本质上来说,也是个目录,所以他也使用了Kobject,来表示他自己的这个目录  
  22.     struct kset_uevent_ops *uevent_ops;    //由于Kset是将很多的有公共特性的Kobject集中到一起,所以这个变量操作,在他的目录下的一些共性操作。  
  23. };  

 

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. 1 struct bus_type {
  2.  2 const char *name; //总线的名称,这个名字理论上并不是sys/bus/下的那些目录的目录名。那些目录的目录名应该是在下面变量 subsys_private p.sbusys的name变量中。但是往往那个name是由这个name赋值的,所以就一样的。但这里要明白的是(还是上面的老生常谈),表示目录是由Kset.Kobject这个东西来表示的。
  3.  3 struct bus_attribute *bus_attrs; //根据后面的bus_add_attrs函数分析,这些个属性可能是数组
  4.  4 struct device_attribute *dev_attrs;
  5.  5 struct driver_attribute *drv_attrs; //bus device driver的属性,一些操作导入导出的属性,等后面再分析。
  6.  6
  7.  7 int (*match)(struct device *dev, struct device_driver *drv);
  8.  8 int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
  9.  9 int (*probe)(struct device *dev);
  10. 10 int (*remove)(struct device *dev);
  11. 11 void (*shutdown)(struct device *dev);
  12. 12
  13. 13 int (*suspend)(struct device *dev, pm_message_t state);
  14. 14 int (*resume)(struct device *dev); //总线的操作
  15. 15
  16. 16 const struct dev_pm_ops *pm; //power manage 的operations
  17. 17
  18. 18 struct subsys_private *p; 见下面:
  19. 19 };
  20.  1 struct subsys_private { //为了保持和上面的代码的连贯,我将这个结构体的注释部分放到下面了。注释还是比较清楚的,不解释
  21.  2  struct kset subsys;
  22.  3 &nbsp;struct kset *devices_kset;</p><p>&nbsp;struct kset *drivers_kset;
  23.  4 &nbsp;struct klist klist_devices;
  24.  5 &nbsp;struct klist klist_drivers;
  25.  6 &nbsp;struct blocking_notifier_head bus_notifier;
  26.  7 &nbsp;unsigned int drivers_autoprobe:1;
  27.  8 &nbsp;struct bus_type *bus;</p><p>&nbsp;struct list_head class_interfaces;
  28.  9 &nbsp;struct kset glue_dirs;
  29. 10 &nbsp;struct mutex class_mutex;
  30. 11 &nbsp;struct class *class;
  31. 12 };
  32. 13 &nbsp;* struct subsys_private - structure to hold the private to the driver core portions of the bus_type/class structure.
  33. 14 &nbsp;*
  34. 15 &nbsp;* @subsys - the struct kset that defines this subsystem
  35. 16 &nbsp;* @devices_kset - the list of devices associated
  36. 17 &nbsp;*
  37. 18 &nbsp;* @drivers_kset - the list of drivers associated
  38. 19 &nbsp;* @klist_devices - the klist to iterate over the @devices_kset
  39. 20 &nbsp;* @klist_drivers - the klist to iterate over the @drivers_kset
  40. 21 &nbsp;* @bus_notifier - the bus notifier list for anything that cares about things
  41. 22 &nbsp;*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; on this bus.
  42. 23 &nbsp;* @bus - pointer back to the struct bus_type that this structure is associated
  43. 24 &nbsp;*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with.
  44. 25 &nbsp;*
  45. 26 &nbsp;* @class_interfaces - list of class_interfaces associated
  46. 27 &nbsp;* @glue_dirs - "glue" directory to put in-between the parent device to
  47. 28 &nbsp;*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; avoid namespace conflicts
  48. 29 &nbsp;* @class_mutex - mutex to protect the children, devices, and interfaces lists.
  49. 30 &nbsp;* @class - pointer back to the struct class that this structure is associated
  50. 31 &nbsp;*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with.
  51. 32 &nbsp;*
  52. 33 &nbsp;* This structure is the one that is the actual kobject allowing struct
  53. 34 &nbsp;* bus_type/class to be statically allocated safely.&nbsp; Nothing outside of the
  54. 35 &nbsp;* driver core should ever touch these fields.
  55. 36 &nbsp;*/</p>
  56. 这个结构体用来描述比如:/sys/bus/pci pci总线,/sys/bus/platform platform总线等。

  57. 另外:从这个结构体分析下来,整个bus的目录结构都很清楚了eg:

  58. 1,可以找到总线下的设备目录: bus_type bus ---> subsys_private p---->Kest devices_kset

  59. 2,可以找到总线下的设备驱动目录: bus_type bus ---> subsys_private p---->Kest driver_kset

  60. 另外,找到的也只是目录,因为找到的仅仅是Kset结构。

设备device

首先明白,device这个结构并不是直接挂在bus下的,可以到/sys/bus/platform/device下随便看一下,发现里面的都是link文件,link到/sys/device/下。所以真正的device结构体的在/sys/device下的。

  1. struct device {  
  2.     struct device       *parent;  //设备的父设备指针,那么就是说device的目录也是可以嵌套的?到/sys/device/platform/serial8250目录下看看,竟然还存在着 tty/ 目录,是不是这样嵌套的呢??天知道。。。。。  
  3.   
  4.     struct device_private   *p;  
  5.   
  6.     struct kobject kobj;        //这个就是说了好久的 Kobject  
  7.     const char      *init_name; /* initial name of the device */  
  8.     struct device_type  *type;  
  9.   
  10.     struct mutex        mutex;  /* mutex to synchronize calls to 
  11.                      * its driver. 
  12.                      */  
  13.   
  14.     struct bus_type *bus;       /* type of bus device is on *///他所在的总线的类型  
  15.     struct device_driver *driver;   /* which driver has allocated this  //支持的驱动 
  16.                        device */  
  17.     void        *platform_data; /* Platform specific data, device 
  18.                        core doesn't touch it */  
  19.     struct dev_pm_info  power;  
  20.     struct dev_power_domain *pwr_domain;  
  21.   
  22. #ifdef CONFIG_NUMA  
  23.     int     numa_node;  /* NUMA node this device is close to */  
  24. #endif  
  25.     u64     *dma_mask;  /* dma mask (if dma'able device) */  
  26.     u64     coherent_dma_mask;/* Like dma_mask, but for 
  27.                          alloc_coherent mappings as 
  28.                          not all hardware supports 
  29.                          64 bit addresses for consistent 
  30.                          allocations such descriptors. */  
  31.   
  32.     struct device_dma_parameters *dma_parms;  
  33.   
  34.     struct list_head    dma_pools;  /* dma pools (if dma'ble) */  
  35.   
  36.     struct dma_coherent_mem *dma_mem; /* internal for coherent mem 
  37.                          override */  
  38.     /* arch specific additions */  
  39.     struct dev_archdata archdata;  
  40.   
  41.     struct device_node  *of_node; /* associated device tree node */  
  42.   
  43.     dev_t           devt;   /* dev_t, creates the sysfs "dev" */  
  44.   
  45.     spinlock_t      devres_lock;  
  46.     struct list_head    devres_head;  
  47.   
  48.     struct klist_node   knode_class;  
  49.     struct class        *class;  
  50.     const struct attribute_group **groups;  /* optional groups */  
  51.   
  52.     void    (*release)(struct device *dev);  
  53. };  


设备driver

  1. struct device_driver {  
  2.     const char      *name;  
  3.     struct bus_type     *bus;  
  4.   
  5.     struct module       *owner;  
  6.     const char      *mod_name;  /* used for built-in modules */  
  7.   
  8.     bool suppress_bind_attrs;   /* disables bind/unbind via sysfs */  
  9.   
  10.     const struct of_device_id   *of_match_table;  
  11.   
  12.     int (*probe) (struct device *dev);  
  13.     int (*remove) (struct device *dev);  
  14.     void (*shutdown) (struct device *dev);  
  15.     int (*suspend) (struct device *dev, pm_message_t state);  
  16.     int (*resume) (struct device *dev);  
  17.     const struct attribute_group **groups;  
  18.   
  19.     const struct dev_pm_ops *pm;  
  20.   
  21.     struct driver_private *p;  
  22. };  

 

 

设备模型的注册等操作:

 

总线的操作:

用户可以自己注册一个总线,然后将自己喜欢的设备和驱动挂载到下面。但是linux 2.6中,有个默认的总线,platform总线。我们就分析一下这个总线。

小记:随手在Source insight里敲了个 platform_bus_init,结果的真的有这个函数,再看一下谁调用他了吧? 竟然是drive_init。啊。。终于找到组织了,在start_kernel的最后一步后调用这个drive_init了。

  1. int __init platform_bus_init(void)  
  2. {  
  3.     int error;  
  4.   
  5.     early_platform_cleanup();  //清除platform总线上的设备?不确定,,,好像就是将early_platform_device_list这个里的内容清空。  
  6.   
  7.     error = device_register(&platform_bus);  //设备注册。哦,linux将platform也当成了一个设备,他在/sys/device目录下。当然,以后会在platform这个设备下再建立其他的设备,回顾刚才介绍device结构体时候有个parent变量,应该就是用在这里的。具体device_register这个函数,后面再介绍  
  8.     if (error)  
  9.         return error;  
  10.     error =  bus_register(&platform_bus_type);  //总线的注册。  
  11.     if (error)  
  12.         device_unregister(&platform_bus);  
  13.     return error;  
  14. }  

 

  1.  * bus_register - register a bus with the system. 
  2.  * @bus: bus. 
  3.  * 
  4.  * Once we have that, we registered the bus with the kobject 
  5.  * infrastructure, then register the children subsystems it has: 
  6.  * the devices and drivers that belong to the bus. 
  7.  */  
  8. int bus_register(struct bus_type *bus)  
  9. {  
  10.     int retval;  
  11.     struct subsys_private *priv;  
  12.   
  13.     priv = kzalloc(sizeof(struct subsys_private), GFP_KERNEL);  
  14.     if (!priv)  
  15.         return -ENOMEM;  
  16.   
  17.     priv->bus = bus;  
  18.     bus->p = priv;  
  19.   
  20.     BLOCKING_INIT_NOTIFIER_HEAD(&priv->bus_notifier);       //bus_notifier就是个读写信号量,和RCU机制,这里进行初始化  
  21.   
  22.     retval = kobject_set_name(&priv->subsys.kobj, "%s", bus->name);  //设置name,这个name会显示在sys/bus/下  
  23.     if (retval)  
  24.         goto out;  
  25.   
  26.     priv->subsys.kobj.kset = bus_kset;  
  27.     priv->subsys.kobj.ktype = &bus_ktype;  
  28.     priv->drivers_autoprobe = 1;  
  29.   
  30.     retval = kset_register(&priv->subsys);               //这个应该是注册bus,但看函数名是ket_register,所以可能会根据刚才对subsys.kobj.kset的赋值来判定是bus,并注册。后面分析。  
  31.     if (retval)  
  32.         goto out;  
  33.   
  34.     retval = bus_create_file(bus, &bus_attr_uevent);       //在对应的bus目录下,根据attribute来创建一个文件  
  35.     if (retval)  
  36.         goto bus_uevent_fail;  
  37.   
  38.     priv->devices_kset = kset_create_and_add("devices", NULL,                  //这就函数应该是创建目录,所以在每个bus下会有 device和driver 两个目录。  
  39.                          &priv->subsys.kobj);  
  40.     if (!priv->devices_kset) {  
  41.         retval = -ENOMEM;  
  42.         goto bus_devices_fail;  
  43.     }  
  44.   
  45.     priv->drivers_kset = kset_create_and_add("drivers", NULL,  
  46.                          &priv->subsys.kobj);  
  47.     if (!priv->drivers_kset) {  
  48.         retval = -ENOMEM;  
  49.         goto bus_drivers_fail;  
  50.     }  
  51.   
  52.     klist_init(&priv->klist_devices, klist_devices_get, klist_devices_put);  
  53.     klist_init(&priv->klist_drivers, NULL, NULL);       //klist还是没搞明白怎么用,以后再说吧  
  54.   
  55.     retval = add_probe_files(bus);       //这个也是在对应的总线目录下,建立bus_attr_drivers_probe 和 bus_attr_drivers_autoprobe文件。应该是probe的时候使用。  
  56.     if (retval)  
  57.         goto bus_probe_files_fail;  
  58.   
  59.     retval = bus_add_attrs(bus);  //循环将所有的bus的属性都建立成一个文件。  
  60.     if (retval)  
  61.         goto bus_attrs_fail;  
  62.   
  63.     pr_debug("bus: '%s': registered\n", bus->name);  
  64.     return 0;  
  65.   
  66. bus_attrs_fail:  
  67.     remove_probe_files(bus);  
  68. bus_probe_files_fail:  
  69.     kset_unregister(bus->p->drivers_kset);  
  70. bus_drivers_fail:  
  71.     kset_unregister(bus->p->devices_kset);  
  72. bus_devices_fail:  
  73.     bus_remove_file(bus, &bus_attr_uevent);  
  74. bus_uevent_fail:  
  75.     kset_unregister(&bus->p->subsys);  
  76. out:  
  77.     kfree(bus->p);  
  78.     bus->p = NULL;  
  79.     return retval;  
  80. }  


  /** 

  kset_register - initialize and add a kset. 

  1.  * @k: kset. 
  2.  */  
  3. int kset_register(struct kset *k)  
  4. {  
  5.     int err;  
  6.   
  7.     if (!k)  
  8.         return -EINVAL;  
  9.   
  10.     kset_init(k);          //初始化,没什么东西  
  11.     err = kobject_add_internal(&k->kobj);  //下面分析  
  12.     if (err)  
  13.         return err;  
  14.     kobject_uevent(&k->kobj, KOBJ_ADD);    //通过这个函数的注释可知,向usrspace发送信号。  
  15.     return 0;  
  16. }  
  1. static int kobject_add_internal(struct kobject *kobj)  
  2. {  
  3.  int error = 0;  
  4.  struct kobject *parent;

     if (!kobj)  

  5.   return -ENOENT;

     if (!kobj->name || !kobj->name[0]) {  

  6.   WARN(1, "kobject: (%p): attempted to be registered with empty "  
  7.     "name!\n", kobj);  
  8.   return -EINVAL;  
  9.  }
  10.  
  11. parent = kobject_get(kobj->parent);

     /* join kset if set, use it as parent if we do not already have one */  

  12.  if (kobj->kset) {  
  13.   if (!parent)  
  14.    parent = kobject_get(&kobj->kset->kobj);   //get kobject->kset, 判断与parent对比。        
  15. obj_kset_join(kobj);         //这个函数,是将kobject的entry这个变量 添加到 他的 上一级的kset结构的 list中。  
  16.   kobj->parent = parent;  
  17.  }
  18.  
  19.  
  20. pr_debug("kobject: '%s' (%p): %s: parent: '%s', set: '%s'\n",  
  21.    kobject_name(kobj), kobj, __func__,  
  22.    parent ? kobject_name(parent) : "",  
  23.    kobj->kset ? kobject_name(&kobj->kset->kobj) : "");

     error = create_dir(kobj);   //创建目录。比如:/sys/bus 下的 platform, pci等目录。  

  24.  if (error) {  
  25.   kobj_kset_leave(kobj);  
  26.   kobject_put(parent);  
  27.   kobj->parent = NULL;

      /* be noisy on error issues */  

  28.   if (error == -EEXIST)  
  29.    printk(KERN_ERR "%s failed for %s with "  
  30.           "-EEXIST, don't try to register things with "  
  31.           "the same name in the same directory.\n",  
  32.           __func__, kobject_name(kobj));  
  33.   else  
  34.    printk(KERN_ERR "%s failed for %s (%d)\n",  
  35.           __func__, kobject_name(kobj), error);  
  36.   dump_stack();  
  37.  } else  
  38.   kobj->state_in_sysfs = 1;

     return error;  

  39. }

      

到此,bus_register解释完成。

 

  1.  * device_register - register a device with the system. 
  2.  * @dev: pointer to the device structure 
  3.  * 
  4.  * This happens in two clean steps - initialize the device 
  5.  * and add it to the system. The two steps can be called 
  6.  * separately, but this is the easiest and most common. 
  7.  * I.e. you should only call the two helpers separately if 
  8.  * have a clearly defined need to use and refcount the device 
  9.  * before it is added to the hierarchy. 
  10.  * 
  11.  * NOTE: _Never_ directly free @dev after calling this function, even 
  12.  * if it returned an error! Always use put_device() to give up the 
  13.  * reference initialized in this function instead. 
  14.  */  
  15. int device_register(struct device *dev)  
  16. {  
  17.     device_initialize(dev);  
  18.     return device_add(dev);  
  19. }  
  1.  * device_initialize - init device structure. 
  2.  * @dev: device. 
  3.  * 
  4.  * This prepares the device for use by other layers by initializing 
  5.  * its fields. 
  6.  * It is the first half of device_register(), if called by 
  7.  * that function, though it can also be called separately, so one 
  8.  * may use @dev's fields. In particular, get_device()/put_device() 
  9.  * may be used for reference counting of @dev after calling this 
  10.  * function. 
  11.  * 
  12.  * NOTE: Use put_device() to give up your reference instead of freeing 
  13.  * @dev directly once you have called this function. 
  14.  */  
  15. void device_initialize(struct device *dev)  
  16. {  
  17.     dev->kobj.kset = devices_kset;  
  18.     kobject_init(&dev->kobj, &device_ktype);  
  19.     INIT_LIST_HEAD(&dev->dma_pools);  
  20.     mutex_init(&dev->mutex);  
  21.     lockdep_set_novalidate_class(&dev->mutex);  
  22.     spin_lock_init(&dev->devres_lock);  
  23.     INIT_LIST_HEAD(&dev->devres_head);  
  24.     device_pm_init(dev);  
  25.     set_dev_node(dev, -1);  
  26. }  


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

啪,一道雷劈死我了。答曰:你知道的太多了。  为了留条命,就不解释了。

 

  1. /** 
  2.  * device_add - add device to device hierarchy. 
  3.  * @dev: device. 
  4.  * 
  5.  * This is part 2 of device_register(), though may be called 
  6.  * separately _iff_ device_initialize() has been called separately. 
  7.  * 
  8.  * This adds @dev to the kobject hierarchy via kobject_add(), adds it 
  9.  * to the global and sibling lists for the device, then 
  10.  * adds it to the other relevant subsystems of the driver model. 
  11.  * 
  12.  * NOTE: _Never_ directly free @dev after calling this function, even 
  13.  * if it returned an error! Always use put_device() to give up your 
  14.  * reference instead. 
  15.  */  
  16. int device_add(struct device *dev)  
  17. {  
  18.     struct device *parent = NULL;  
  19.     struct class_interface *class_intf;  
  20.     int error = -EINVAL;  
  21.   
  22.     dev = get_device(dev);  
  23.     if (!dev)  
  24.         goto done;  
  25.   
  26.     if (!dev->p) {  
  27.         error = device_private_init(dev);  
  28.         if (error)  
  29.             goto done;  
  30.     }  
  31.   
  32.     /* 
  33.      * for statically allocated devices, which should all be converted 
  34.      * some day, we need to initialize the name. We prevent reading back 
  35.      * the name, and force the use of dev_name() 
  36.      */  
  37.     if (dev->init_name) {  
  38.         dev_set_name(dev, "%s", dev->init_name);  
  39.         dev->init_name = NULL;  
  40.     }  
  41.   
  42.     if (!dev_name(dev)) {  
  43.         error = -EINVAL;  
  44.         goto name_error;  
  45.     }  
  46.   
  47.     pr_debug("device: '%s': %s\n", dev_name(dev), __func__);  
  48.   
  49.     parent = get_device(dev->parent);  
  50.     setup_parent(dev, parent);  
  51.   
  52.     /* use parent numa_node */  
  53.     if (parent)  
  54.         set_dev_node(dev, dev_to_node(parent));  
  55.     //以上是对device进行初始化,包括name,private,parent……  
  56.     /* first, register with generic layer. */  
  57.     /* we require the name to be set before, and pass NULL */  
  58.     error = kobject_add(&dev->kobj, dev->kobj.parent, NULL);   //device添加,根据他的parent等,当然还会根据他的attribute built一些文件。  
  59.     if (error)  
  60.         goto Error;  
  61.   
  62.     /* notify platform of device entry */  
  63.     if (platform_notify)  
  64.         platform_notify(dev);  
  65.   
  66.     error = device_create_file(dev, &uevent_attr);  //built attr file  
  67.     if (error)  
  68.         goto attrError;  
  69.   
  70.     if (MAJOR(dev->devt)) {  
  71.         error = device_create_file(dev, &devt_attr);  
  72.         if (error)  
  73.             goto ueventattrError;  
  74.   
  75.         error = device_create_sys_dev_entry(dev);  
  76.         if (error)  
  77.             goto devtattrError;  
  78.   
  79.         devtmpfs_create_node(dev);  
  80.     }  
  81.   
  82.     error = device_add_class_symlinks(dev);         //在其他文件夹 建立link文件,这就是为什么在class目录下也能看到device的目录和文件了  
  83.     if (error)  
  84.         goto SymlinkError;  
  85.     error = device_add_attrs(dev);  
  86.     if (error)  
  87.         goto AttrsError;  
  88.     error = bus_add_device(dev);      //在bus目录下 建立link文件,所以在/sys/bus/platform/device下回看到n多个link文件。  
  89.     if (error)  
  90.         goto BusError;  
  91.     error = dpm_sysfs_add(dev);  
  92.     if (error)  
  93.         goto DPMError;  
  94.     device_pm_add(dev);  
  95.   
  96.     /* Notify clients of device addition.  This call must come 
  97.      * after dpm_sysf_add() and before kobject_uevent(). 
  98.      */  
  99.     if (dev->bus)  
  100.         blocking_notifier_call_chain(&dev->bus->p->bus_notifier,  
  101.                          BUS_NOTIFY_ADD_DEVICE, dev);  
  102.   
  103.     kobject_uevent(&dev->kobj, KOBJ_ADD);  
  104.     bus_probe_device(dev);         //进行probe,看有没和device相对应的driver文件。  
  105.     if (parent)  
  106.         klist_add_tail(&dev->p->knode_parent,  
  107.                    &parent->p->klist_children);  
  108.   
  109.     if (dev->class) {  
  110.         mutex_lock(&dev->class->p->class_mutex);  
  111.         /* tie the class to the device */  
  112.         klist_add_tail(&dev->knode_class,  
  113.                    &dev->class->p->klist_devices);  
  114.   
  115.         /* notify any interfaces that the device is here */  
  116.         list_for_each_entry(class_intf,  
  117.                     &dev->class->p->class_interfaces, node)  
  118.             if (class_intf->add_dev)  
  119.                 class_intf->add_dev(dev, class_intf);  
  120.         mutex_unlock(&dev->class->p->class_mutex);  
  121.     }  
  122. done:  
  123.     put_device(dev);  
  124.     return error;  
  125.  DPMError:  
  126.     bus_remove_device(dev);  
  127.  BusError:  
  128.     device_remove_attrs(dev);  
  129.  AttrsError:  
  130.     device_remove_class_symlinks(dev);  
  131.  SymlinkError:  
  132.     if (MAJOR(dev->devt))  
  133.         devtmpfs_delete_node(dev);  
  134.     if (MAJOR(dev->devt))  
  135.         device_remove_sys_dev_entry(dev);  
  136.  devtattrError:  
  137.     if (MAJOR(dev->devt))  
  138.         device_remove_file(dev, &devt_attr);  
  139.  ueventattrError:  
  140.     device_remove_file(dev, &uevent_attr);  
  141.  attrError:  
  142.     kobject_uevent(&dev->kobj, KOBJ_REMOVE);  
  143.     kobject_del(&dev->kobj);  
  144.  Error:  
  145.     cleanup_device_parent(dev);  
  146.     if (parent)  
  147.         put_device(parent);  
  148. name_error:  
  149.     kfree(dev->p);  
  150.     dev->p = NULL;  
  151.     goto done;  
  152. }  



当然还有 drive_register的函数,其实和device_register差不多,另外,driver_register也会在最后进行probe,看有没有相应的设备。driver_register会先check这个drvier所在的bus上有没有probe函数,如果有就运行这个函数进行probe,如果没有,就运行自己的probe进行probe,这就是我们在驱动中经常看到的probe函数。

所以,在驱动中,先运行drive_register和先运行device_register都是一样的。

 

到这里,我们看完了platform总线如何对底层的kobject的封装机制了吧???亲们是否明白了呢???呵呵,下面的驱动内容会介绍不同的封装类型,请注意面向对象的思想。

阅读(585) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~