LDD 3rd 中文版实在是让我忍无可忍，USB驱动一章翻译得那是相当的晦涩，看得我云里雾里，索性扔下书来看代码，以后主要靠自己分析代码学习，多读网上前辈的笔记，这样不仅能加深对代码的理解，也看到了别人的思维角度，比抱着LDD 3rd啃强多了，开搞！

新手自学笔记，比较罗嗦，冗长，学到什么地方就写到什么地方，没有具体的层次和顺序。写这个笔记的目的，仅仅是当作备忘和一个过程的记录，如果高手看到了谬误之处，敬请斧正。

全部代码、笔记、实验都在Debian GNU/Linux 下进行，内核版本如下：

ganquan@debian:~$ uname -r

2.6.26-2-686

0.先从阅读usb-skeleton.c开始

ganquan@debian:~$ cat /usr/src/linux-source-2.6.26/drivers/usb/usb-skeleton.c | wc -l

525

还好，只有525行。不算吓人。

从驱动程序的Hello World开始看：

504    static int __init usb_skel_init(void)
 
505    {
 
506        int result;
 
507
 
508        /* register this driver with the USB subsystem */
 
509        result = usb_register(&skel_driver);
 
510        if (result)
 
511            err("usb_register failed. Error number %d", result);
 
512
 
513        return result;
 
514    }
 
515
 
516    static void __exit usb_skel_exit(void)
 
517    {
 
518        /* deregister this driver with the USB subsystem */
 
519        usb_deregister(&skel_driver);
 
520    }

显然的，504行的usb_skel_init(void)就是insmod之后被运行的初始化函数，它只干了一件事：调用usb_register函数，注册了一个叫skel_driver的东西，skel_driver是在usb-skeleton.c 文件67行定义的一个usb_driver类型的结构体。再来看看usb_driver到底是何方妖孽。

在linux-source-2.6.26/include/linux/usb.h里面，991行到1015行定义了这个结构体如下：

991 struct usb_driver {
 
992 const char *name;
 
993
 
994 int (*probe) (struct usb_interface *intf,
 
995 const struct usb_device_id *id);
 
996
 
997 void (*disconnect) (struct usb_interface *intf);
 
998
 
999 int (*ioctl) (struct usb_interface *intf, unsigned int code,
 
1000 void *buf);
 
1001
 
1002 int (*suspend) (struct usb_interface *intf, pm_message_t message);
 
1003 int (*resume) (struct usb_interface *intf);
 
1004 int (*reset_resume)(struct usb_interface *intf);
 
1005
 
1006 int (*pre_reset)(struct usb_interface *intf);
 
1007 int (*post_reset)(struct usb_interface *intf);
 
1008
 
1009 const struct usb_device_id *id_table;
 
1010
 
1011 struct usb_dynids dynids;
 
1012 struct usbdrv_wrap drvwrap;
 
1013 unsigned int no_dynamic_id:1;
 
1014 unsigned int supports_autosuspend:1;
 
1015 };

可见这个结构体包含了不少函数指针，通过名字大概猜了一下各个回调函数里面应该干啥，结构体中各个字段在内核代码中都有详细注释，不再一一叙述。总之，这个结构体现在看来，是用于标识我的USB驱动程序的。

搞清楚了传递给usb_register函数的参数，再看来看这个函数是干啥的。

还是在linux-source-2.6.26/include/linux/usb.h里面，有：

1075 static inline int usb_register(struct usb_driver *driver)
 
1076 {
 
1077 return usb_register_driver(driver, THIS_MODULE, KBUILD_MODNAME);
 
1078 }

这个内联函数居然又调用了另外一个函数，内核真是一个蜘蛛网，一点也不假，继续看：

usb_register_driver函数，第一个参数是用来标识USB驱动程序的usb_driver类型的结构体，第二、三个参数都是宏，但是第二个参数其实是一个module类型的结构体，第三个参数是字符指针，这两个参数暂时不分析。先放着就可以了。

接下来看一下usb_register_driver函数又干了什么。

在linux-source-2.6.26/driver/usb/core/driver.c中：

715 int usb_register_driver(struct usb_driver *new_driver, struct module *owner,
 
716 const char *mod_name)
 
717 {
 
718 int retval = 0;
 
719
 
720 if (usb_disabled())
 
721 return -ENODEV;
 
722
 
723 new_driver->drvwrap.for_devices = 0;
 
724 new_driver->drvwrap.driver.name = (char *) new_driver->name;
 
725 new_driver->drvwrap.driver.bus = &usb_bus_type;
 
726 new_driver->drvwrap.driver.probe = usb_probe_interface;
 
727 new_driver->drvwrap.driver.remove = usb_unbind_interface;
 
728 new_driver->drvwrap.driver.owner = owner;
 
729 new_driver->drvwrap.driver.mod_name = mod_name;
 
730 spin_lock_init(&new_driver->dynids.lock);
 
731 INIT_LIST_HEAD(&new_drive->dynids.list);
 
732
 
733 retval = driver_register(&new_driver->drvwrap.driver);
 
734
 
735 if (!retval) {
 
736 pr_info("%s: registered new interface driver %s\n",
 
737 usbcore_name, new_driver->name);
 
738 usbfs_update_special();
 
739 usb_create_newid_file(new_driver);
 
740 } else {
 
741 printk(KERN_ERR "%s: error %d registering interface "
 
742 " driver %s\n",
 
743 usbcore_name, retval, new_driver->name);
 
744 }
 
745
 
746 return retval;
 
747 }

以上可见usb_register_driver函数中对usb_driver结构体的一个成员赋值，也就是对drvwrap成员。drvwrap是一个结构体，函数中对它的driver成员的各个字段进行赋值，并且usb_register_driver函数中还调用了一个driver_register函数，传入参数是drvwap的driver字段，看来这个drvwap成员分量不轻，现在去探究一下 这个usbdrv_wrap类型的drvwrap又是什么。

在linux-source-2.6.26/include/linux/usb.h中：

934 struct usbdrv_wrap {
 
935 struct device_driver driver;
 
936 int for_devices;
 
937 };

可见，usbdrv_wrap只不过是一个对device_driver的封装，继续深入看一下device_driver又是什么。

在linux-source-2.6.26/include/linux/device.h中：

120 struct device_driver {
 
121 const char *name;
 
122 struct bus_type *bus;
 
123
 
124 struct module *owner;
 
125 const char *mod_name; /* used for built-in modules */
 
126
 
127 int (*probe) (struct device *dev);
 
128 int (*remove) (struct device *dev);
 
129 void (*shutdown) (struct device *dev);
 
130 int (*suspend) (struct device *dev, pm_message_t state);
 
131 int (*resume) (struct device *dev);
 
132 struct attribute_group **groups;
 
133
 
134 struct driver_private *p;
 
135 };

注意到device_driver的定义，134行又是一个driver_private结构体指针。非常有必要弄清楚这个结构体。

在linux-source-2.6.26/driver/base/base.h中，有：

30 struct driver_private {
 
31 struct kobject kobj;
 
32 struct klist klist_devices;
 
33 struct klist_node knode_bus;
 
34 struct module_kobject *mkobj;
 
35 struct device_driver *driver;
 
36 };

继续深入看看kobject又长什么样子。

在linux-source-2.6.26/include/linux/kobject.h中：

60 struct kobject {
 
61 const char *name;
 
62 struct kref kref;
 
63 struct list_head entry;
 
64 struct kobject *parent;
 
65 struct kset *kset;
 
66 struct kobj_type *ktype;
 
67 struct sysfs_dirent *sd;
 
68 unsigned int state_initialized:1;
 
69 unsigned int state_in_sysfs:1;
 
70 unsigned int state_add_uevent_sent:1;
 
71 unsigned int state_remove_uevent_sent:1;
 
72 };

到底了，为啥到底了。去看看linux-source-2.6.26/Document/kobject.txt就知道为啥到底了。

那么kobject到底是个啥？

kobject就是组成Linux的设备模型的基本数据结构。kobject的任务有：

(1)对内核对象的计数，对应数据结构就是struct kref

(2)sysfs表述

(3)数据结构关联

(4)热插拔处理

对usb_driver一层一层的拨开，最后走到了kobject。在内核设计中也用到了面向对象的思想，kobject就可以当作基类，其他的类都是从kobject继承的，由于C语言不能像C++那样继承，所以就一次又一次的封装。

我现在搞清楚了各个struct之间的关系：

kobject—>driver_private—>device_driver—>usbdrv_wrap—>usb_driver

总结他们之间的关系如下：

kobject是Linux设备模型的基本数据结构，它被作为“基类”，其他“子类”都是“继承”了kobject。在我分析的这个例子中，driver_private就是一个“子类”，它直接“继承”了kobject。事实上，老版本的内核(2.6.10)直接把kobject放在device_driver中，新版本的内核则是用driver_private来存放kobject，然后再把driver_private封装在device_driver中。device_driver中除了包含driver_private，还有很多函数指针，也就是驱动程序需要提供的服务。接下来，usbdrv_wrap再次封装了device_driver，这次封装很简单，没有增加过多额外的字段。最后usb_driver来封装usbdrv_wrap，usb_driver中也有很多的函数指针。

这些结构体的各个字段，具体作用是什么？尤其是最接近“基类”的那些“子类”的以k开头的字段，都用来实现什么功能？

驱动程序提供的服务又是什么样子，以及USB驱动程序在总线上的挂牌过程，这些都需要弄明白，下一篇笔记看看能不能弄清楚。