关于klist

          今天在公司看linux driver相关的内容，现在出来背下书。看klist.c这个文件，klist这个kernel list是继承了list_head这个单纯的链表，在它的基础上添加了kref的引用计数的功能。kref是一个引用计数的原子操作的变量。put的是时候，kref的值减1，get的时候加1。内核里的对象object都是用这个kref判断对象何时releas该对象的。刚创建的时候，kref的为1，当通过put函数使kref变为0的时候，就调用release函数释放这个对象的内存空间。klist的k_node的成员只多了一个kref，然后把这个k_node嵌套到其他object里，形成能计引用个数的双向。klist的链表头也添加了put和get这两个操作函数的指针。为啥要看这个klist？因为在bus上，挂所有的device和device_driver对象，就是通过两个klist分别把这个bus_type的device和device_driver连起来的。同时在bus上添加device_driver时，会迭代 iterate这个bus上所有的device，尝试和这个device_driver进行match（这个match是bus的match方法）。如果match成功，则调用device_driver的probe函数，对进行设备进行相应的初始化。

关于kref：内核中的代表对象kobject包含kref，且内核中的bus、device、device_driver都是继承这个kobject。这kref就是为了判断对象是否能被release，是否还有别的地方引用该对象。

klist应该是kernel list的缩写，而不是kref listd的 缩写，有人在邮件列表中问了。

关于cdev、block_dev和这个bus device device_driver驱动模型的关系：暂时还不是很清楚，但是我觉得这个cdev和block_dev应该在这个驱动模型的上面，cdev和block_dev这两个概念应该在这个驱动模型的上面一层（更接近file），他们应该不是一个层的概念。

sysfs文件系统：原文是把内核里的对象和对象之间的关系export导出到userspace用户空间。让用户能够访问。但是这能访问的都是简单的，因为用户读写的attribute属性都是ascii的字符串。

内核中每个继承了object的对象，都会在sysfs中生成对应的目录或文件。

这个klist简单的继承了list_head ，写的也很干净clean，所以内核中链接对象的时候，都会通过这个klist来链接，既能链接对象，又能进行引用计数。