struct bus_type中为设备和驱动准备了两个链表,而代表设备的结构体struct device中又有两个成员,struct bus_type *bus和struct device_driver *driver。同样,代表驱动的结构体struct device_driver同样有两个成员,struct bus_type *bus和struct list_head devices,struct device和struct device_driver的定义和struct bus_type一样,在include/linux/device.h中。凭直觉,可以知道,struct device中的bus记录的是这个设备连在哪条总线上,driver记录的是这个设备用的是哪个驱动。反过来,struct device_driver中的bus代表的也是这个驱动属于哪条总线,devices记录的是这个驱动支持的那些设备。没错,是devices(复数),而不是device(单数),因为一个驱动程序可以支持一个或多个设备,反过来一个设备则只会绑定给一个驱动程序。
于是我们想知道,关于bus,关于device,关于driver,它们是如何建立联系的呢?换而言之,这三个数据结构中的指针是如何被赋值的?绝对不可能发生的事情是,一旦为一条总线申请了一个struct bus_type的数据结构之后,它就知道它的devices链表和drivers链表会包含哪些东西,这些东西一定不会是先天就有的,只能是后来填进来的。
而具体到USB系统,完成这个工作的就是USB Core。USB Core的代码会进行整个USB系统的初始化,比如申请struct bus_typeusb_bus_type,然后会扫描USB总线,看线上连接了哪些USB设备。或者说Root Hub上连了哪些USB设备,比如说连了一个USB键盘,那么就为它准备一个struct device,根据它的实际情况,为这个struct device赋值,并插入devices链表中来。又比如Root Hub上连了一个普通的Hub,那么除了要为这个Hub本身准备一个struct device以外,还得继续扫描看这个Hub上是否又连了别的设备,如果有的话继续重复之前的事情,这样一直进行下去,直到完成整个扫描,最终就把usb_bus_type中的devices链表给建立了起来。
那drivers链表呢?这个就不用bus方面主动了,而该由每一个驱动本身去bus上面登记,或者说挂牌。具体到USB系统,每一个USB设备的驱动程序都会有一个struct usb_driver结构体,其代码如下,来自include/linux/usb.h:
833 struct usb_driver {
834 const char *name;
835
836 int (*probe) (struct usb_interface*intf,
837const struct usb_device_id *id);
838
839 void(*disconnect) (struct usb_interface *intf);
840
841 int (*ioctl) (struct usb_interface*intf, unsigned int code,
842void *buf);
843
844 int (*suspend) (struct usb_interface *intf,pm_message_t message);
845 int(*resume) (struct usb_interface *intf);
846
847 void(*pre_reset) (struct usb_interface *intf);
848 void (*post_reset) (structusb_interface *intf);
849
850 conststruct usb_device_id *id_table;
851
852 structusb_dynids dynids;
853 struct usbdrv_wrap drvwrap;
854 unsignedint no_dynamic_id:1;
855 unsignedint supports_autosuspend:1;
856 };
857 #define to_usb_driver(d) \
container_of(d,struct usb_driver, drvwrap.driver)
此刻我们只需注意到其中的structdevice_driver driver这个成员,USB Core为每一个设备驱动准备了一个函数,让它把这个struct device_driver driver插入到usb_bus_type中的drivers链表中去。而这个函数正是我们此前看到的usb_register。而与之对应的usb_deregister函数所从事的正是与之相反的工作,把这个结构体从drivers链表中删除。
可以说,USB Core的确是用心良苦,为每一个USB设备驱动做足了功课,正因为如此,作为一个实际的USB设备驱动,它在初始化阶段所要做的事情就很少,很简单了,直接调用usb_register即可。事实上,没有人是理所当然应该为你做什么的,但USB Core这么做了。所以每一个写USB设备驱动的人应该铭记,USB设备驱动绝不是一个人在工作,在他身后,是USB Core所提供的默默无闻又不可或缺的支持。
分享到:
相关推荐
对于Linux驱动开发者,可以通过本书对设备模型有形象深刻的理解;对于USB开发者,可以通过本书全面的理解USB在一个操作系统中的实现;对于Linux内核开发者,也可以通过本书学习到很多Linux高手开发维护一个完整子...
Linux那些事儿之我是U盘 Linux那些事儿之我是Hub Linux那些事儿之我是USB Core Linux那些事儿之我是UHCI Linux那些事儿之我是EHCI控制器 Linux那些事儿之我是PCI Linux那些事儿之我是SCSI硬盘 Linux那些事儿之我是...
Linux那些事儿之我是U盘-有书签版.pdf
读过《linux那些事儿之我是U盘》的人,都知道其风格,我就不多说了。 导读: linux那些事儿之我是U盘 linux那些事儿之我是HUB linux那些事儿之我是USB Core linux那些事儿之我是UHCI Linux那些事儿之我是EHCI主机控制...
里面包含Linux那些事的九个文档,Block层,ECHI主机控制,HUB,PCI,SCSI硬盘,Sysfs,UHCI,USB+core,U盘等九个文档,内容详细,而且全面都有书签,适合系统学习!
Linux那些事儿之我是U盘
导读.doc Linux那些事儿之我是Block层.pdf Linux那些事儿之我是EHCI主机控制器.pdf Linux那些事儿之我是Hub.pdf Linux那些事儿之我是USB_core.pdf Linux那些事儿之我是U盘.pdf等等 Linux那些事儿系列全在这里了
linux哪些事儿之我是usbcore echi pci u盘 sysfs linux哪些事儿之我是usbcore echi pci u盘 sysfs
》包括《Linux那些事儿之我是Hub》、《Linux那些事儿之我是Sysfs》《Linux那些事儿之我是UHCI》、《Linux那些事儿之我是USB core》、《Linux那些事儿之我是U盘》,令人叹为观止的一个linux系列书籍。只能说,江山代...
Linux那些事儿之我是Block层 Linux那些事儿之我是EHCI主机控制器 Linux那些事儿之我是Hub Linux那些事儿之我是PCI Linux那些事儿之我是SCSI硬盘 Linux那些事儿之我是Sysfs ...Linux那些事儿之我是U盘
Linux那些事儿之我是Hub,是前面Linux那些事之我是U盘,usb等的姐妹篇
Linux那些事儿之我是XXX全集 包含USB core U盘 UHCI PCI SCSI硬盘 Block Hub EHCI 。 想学驱动的童鞋,不妨看看。该书主要是进行源代码的分析
Linux那些事儿 Linux那些事儿之我是Block层 Linux那些事儿之我是Sysfs Linux那些事儿之我是U盘
Linux那些事儿之我是Block层.pdf Linux那些事儿之我是EHCI主机控制器.pdf Linux那些事儿之我是PCI.pdf Linux那些事儿之我是SCSI硬盘.pdf 注: 之前有人已经上传了《Linux那些事儿 系列》,其已经包含了:hub,sysfs...
Linux那些事儿之我是U盘 Linux那些事儿之我是USB_core Linux那些事儿之我是UHCI Linux那些事儿之我是Sysfs Linux那些事儿之我是SCSI硬盘 Linux那些事儿之我是PCI Linux那些事儿之我是Hub Linux那些事儿之我是EHCI...
Linux下的硬件驱动——USB设备(下)
本人整理的fudan_abc的专栏中以完结的文章,在此向原作者表示感谢,给...内容包括:linux那些事儿之我是U盘,linux那些事儿之我是USB,linux那些事儿之我是HUB,linux那些事儿之我是UHCI,linux那些事儿之我是Sysfs。