- 论坛徽章:
- 0
|
我们看到其useProtocol 这一栏里写了US_SC_UFI,这表明它自称是属于UFI 这个subclass 的,但是如
果我们从它的描述符里边读出来也是这个,那就没有必要注明在这里了,这里直接写成US_SC_DEVICE 好
了.当然,总的来说这段代码有些傻.写代码的是希望能够更好的管理unusual_devs.h, 希望它不要不断的
增加,他总希望能够从这个文件里删除一些行,并且即使不能删除一行,也希望每一行都看上去整齐一点,让
这个文件看上去更加小巧玲珑,更加精致.而不是无休的增加,不息的扩充.于是我们也只能对其良苦用心多
一份理解吧.
518 至526 行,这里调用了一个来自usb core 的函数,usb_string, 这个函数的作用是获得一个设备的字
符串描述符.咦?怎么跳出来一个叫做字符串描述符的冬冬?之前不是只讲了四种描述符吗?没错,设备描述
符,配置描述符,接口描述符,端点描述符,这是每个设备都有的,而还有些描述符是可有可无的,字符串描述
符就是这么一种情况,有的设备有,有的设备没有.又比如,hub, 它就有一个hub 描述符,这当然是一般的设
备没有的.那么字符串描述符是干嘛的呢?有些东西模糊一些也未偿不是一件好事,看得太透彻了才知道很
残酷.如果你一定要知道的话,举个例子,我的机器里很多usb 设备,有一个和lspci 类似的命令,可以查看一
下,这个命令就是lsusb. 你也可以试一下,安装一个软件包usbutils, 然后就可以使用这个命令.我们看:
localhost:~/test # lsusb
Bus 004 Device 003: ID 0ea0:1001 Ours Technology, Inc.
Bus 004 Device 002: ID 04b4:6560 Cypress Semiconductor Corp. CY7C65640 USB-2.0
"TetraHub"
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 002: ID 0624:0294 Avocent Corp.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
看这个第二行, Cypress Semiconductor Corp., 这么一长串的东西,你说哪来的?是不是应该从设备里来?
设备的那几个标准描述符,整个描述符的大小也不一定放得下这么一长串,所以,一些设备专门准备了一些字
符串描述符(string descriptor). 就用来记这些长串的东西,我们结合刚才的518 行开始讲,如果设备描述
符里边iManufacturer 不为0,那么调用usb_string, 这句话具体做了什么?就是根据iManufactuer 的值
得到公司名字,而iManufactuer 的第一个字母i,就表示index, 它记录的是真正的公司名字保存在哪一个字
符串描述符中,因为字符串描述符可以有多个,那么必然就有个号码来区分,接下来几行,iProduct 记录了产
品名在第几个字符串描述符中,iSerialNumber 记录了产品序列号在第几个字符串描述中,然后调用
usb_string 这个函数,就把真正的字符串描述符里的冬冬给记录了下来.我们看到,我们三次调用的时候分
别传递了us->vendor,us->product,us->serial. 这样函数调用结束之后,这三个里面就记录了必要的信
息,于是以后我们就可以用了.
得到了us->vendor,us->product,us->serial, 那么下面528 直到547 行就不需要多讲了,就是说如果
得到的东西是空的,(得到的是空可以有两种可能,一个是设备根本就没提供这些字符串描述符,另一种情况
是usb_string 函数没能成功,但是这个函数不成功也无所谓,没影响.)那也没关系,毕竟这些信息我们可有
可无,无非是打印出来给客户看看.如果unusual_dev 里边有的话,那就拷贝过来,如果也没有,那没办法,设
为Unknown.而序列号这个就索性置为None 好了,最后US_DEBUGP 把这些信息给打印出来,如果你打
开了debug 开关,那么你会在日志文件里看到这么一句话,在/var/log/messages 里边. |
|