USB驱动分析3.docVIP

USB驱动分析（三）来源: ChinaUnix博客 　日期： 2008.06.05 21:26　(共有0条评论) 我要评论需要注意的是,这些调试信息得是我们打开了编译选项CONFIG_USB_STORAGE_DEBUG才有意义的,这里也看出来了,如果这个选项为0,那么这几个宏就什么也不干,因为它们被赋为空了.关于US_DEBUG系列的这几个宏,就讲这么多,之后再碰上,将直接过滤掉,不予多说.关于prink和kmalloc,这两个函数也没有太多需要说的,对大多数人来讲,就把printk当成printf,把kmalloc当成malloc即可,只不过是这两个函数是专门用于内核代码中的.一个是打印一些东西,一个是申请内存空间.931行呢?id_index干嘛用的?让我们在下节不见不散吧.Be there or be square!-孙楠如是说.storage_probe这个函数挺有意思的,总长度不足100行,但是干了许多事情,这就像足球场上的后腰,比如切尔西的马克莱莱,在场上并不起眼,但是却为整个团队做出了卓越的贡献.也有很多评论家说银河战舰皇家马德里这几年的衰落正是从赶走这个不起眼的马克莱莱开始的.在讲id_index之前,我们继续贴storage_probe的代码:943? ?? ?? ?init_MUTEX((us-dev_semaphore)); 944? ?? ?? ?init_MUTEX_LOCKED((us-sema)); 945? ?? ?? ?init_completion((us-notify)); 946? ?? ?? ?init_waitqueue_head(us-dev_reset_wait); 947? ?? ?? ?init_waitqueue_head(us-scsi_scan_wait); 948? ?? ?? ?init_completion(us-scsi_scan_done); 949 950? ?? ?? ?/* Associate the us_data structure with the USB device */ 951? ?? ?? ?result = associate_dev(us, intf); 952? ?? ?? ?if (result) 953? ?? ?? ?? ?? ???goto BadDevice; 954 955? ?? ?? ?/* 956? ?? ?? ? * Get the unusual_devs entries and the descriptors 957? ?? ?? ? * 958? ?? ?? ? * id_index is calculated in the declaration to be the index number 959? ?? ?? ? * of the match from the usb_device_id table, so we can find the 960? ?? ?? ? * corresponding entry in the private table. 961? ?? ?? ? */ 962? ?? ?? ?get_device_info(us, id_index); storage_probe这个函数之所以短小,是因为它调用了大量的函数.所以,看起来短短一段代码,实际上却要花费我们读代码的人好几个小时,想想真是觉得不划算,难怪朱自清先生看到这个storage_probe函数的时候,不禁感慨,燕子去了,有再来的时候,杨柳枯了,有再青的时候,桃花谢了,有再开的时候,但是,聪明的你告诉我,我们读这段不足100行的函数花掉的时间为何一去不复返呢?其实我们不知道id_index也不影响对后面问题的理解,甚至某种意义上来说,花太多笔墨去讲这个id_index有一点喧宾夺主的感觉,但是,有时候,有些事情,你明知它是无奈的事,无奈的心情,却还要无奈的面对,无奈的去选择,有时想无奈的逃避都不可能,因为我们都被无奈禁锢了.比如这里,注意到962行出现了一个get_device_info的函数,它的一个参数就是id_index,所以,我们别无选择,只能看看这个id_index究竟是干嘛的.上节我们注意到id_index=id-storage_usb_ids,id我们知道,storage_probe函数的两个形参之一,而storage_usb_ids,不是别人,正是我们曾经赋给usb_storage_driver的成员id_table的值.忘记了id_table的可以回去看.它实际上就是一张表格,告诉全世界我这个driver支持怎样的一些设备.storage_usb_ids同样来自drivers/usb/storage/usb