Linux U盘深度解析：技术内幕与驱动机制

5星 · 超过95%的资源需积分: 10 125 浏览量更新于2024-07-30 收藏 1.2MB PDF 举报

"《Linux那些事儿之我是U盘》是一篇深入浅出的IT技术文章，主要围绕USB技术在Linux系统中的应用和实现展开。作者以其独特的方式讲述了USB技术的发展、Linux内核（Kernel）2.6版本下的USB设备驱动机制，以及与之相关的技术细节，如总线（bus）、设备（device）、驱动程序（driver）等。文章首先通过一个轻松的引子，回顾了USB技术在2005年的背景，然后逐步深入探讨了USB设备如何在Linux系统中注册和通信，特别是介绍了统一请求包（URB）、bulk、control传输类型，以及主机（host）和设备之间的通信管道（pipe）。通过比喻和实例，让读者理解了USB设备驱动的复杂性，比如模块机制的变态特性。章节中，作者以故事化的形式展示了从USB协议到Linux内核实现的全过程，包括总线和设备模型、设备分类、设备注册过程，以及与SCSI（小型计算机系统接口）的对比。特别关注了USB设备的数据结构，如URB的底层实现，以及SCSI数据结构的复杂性，通过"彼岸花的传说"系列章节，形象地阐述了这些抽象概念的实际操作。文章还涉及了驱动程序的开发和调试，如如何处理命令和控制传输，以及SCSI在USB设备中的角色转变。每个部分都穿插了实际的代码示例和生动的比喻，使技术内容既专业又易于理解。《Linux那些事儿之我是U盘》不仅是一篇技术教程，更是一部揭示Linux USB技术内幕的通俗读物，适合对Linux内核工作原理和USB技术感兴趣的读者阅读。通过这篇文章，读者不仅能学到技术知识，还能感受到作者对于技术的热情和幽默的表达方式。"

232 struct usb_driver usb_storage_driver = {

233 .owner = THIS_MODULE,

234 .name = "usb-storage",

235 .probe = storage_probe,

236 .disconnect = storage_disconnect,

237 .id_table = storage_usb_ids,

238 };

可以看到这里定义了一个 struct usb_driver 的结构体变量,usb_storage_driver,关于 usb_driver 我们

上节已经说过了,当时主要说的是其中的成员 driver,而眼下要讲的则是另外几个成员.首先,.owner

和.name 这两个没啥好多说的,owner 这玩艺是用来给模块计数的,每个模块都这么用,赋值总是

THIS_MODULE,而 name 就是这个模块的名字,usb core会处理它,所以如果这个模块正常被加载了的话,

使用 lsmod 命令能看到一个叫做 usb-storage 的模块名.重点要讲一讲,.probe 和.disconnect 以及这个

id_table.

我是谁的他?

probe,disconnect,id_table,这三个咚咚中首先要登场亮相的是 id_table,它是干嘛用的呢?

我们说过,一个 device 只能绑定一个 driver,但 driver并非只能支持一种设备,道理很简单,比如

我有两块 U盘,那么我可以一起都插入,但是我只需要加载一个模块,usb-storage,没听说过插入

两块 U 盘就得加载两次驱动程序的,除非这两块 U 盘本身就得使用不同的驱动程序.也正是因为

一个模块可以被多个设备共用,才会有模块计数这么一个说法.

ok,既然一个 driver可以支持多个 device,那么当发现一个 device的时候,如何知道哪个 driver

才是她的 Mr.Right 呢?这就是 id_table 的用处,让每一个 struct usb_driver 准备一张表,里边

注明该 driver支持哪些设备,这总可以了吧.如果你这个设备属于这张表里的,那么 ok,绑定吧,如

果不属于这张表里的,那么不好意思,您请便.哪凉快上哪去.

来自 struct usb_driver 中的 id_table,

const struct usb_device_id *id_table;

实际上是一个指针,一个 struct usb_device_id 结构体的指针,当然赋了值以后就是代表一个数

组名了,正如我们在定义 struct usb_driver usb_storage_driver 中所赋的值那

样,.id_table=storage_usb_ids,那好,我们来看一下 usb_device_id 这究竟是怎样一个结构

体.

struct usb_device_id 来自 include/linux/mod_devicetable.h,

40 /*

41 * Device table entry for "new style" table-driven USB drivers.

42 * User mode code can read these tables to choose which modules to load.

43 * Declare the table as a MODULE_DEVICE_TABLE.

44 *

45 * A probe() parameter will point to a matching entry from this table.

46 * Use the driver_info field for each match to hold information tied

47 * to that match: device quirks, etc.

48 *

49 * Terminate the driver's table with an all-zeroes entry.

50 * Use the flag values to control which fields are compared.

51 */

53 /**

54 * struct usb_device_id - identifies USB devices for probing and hotplugging

55 * @match_flags: Bit mask controlling of the other fields are used to match

56 * against new devices. Any field except for driver_info may be used,

57 * although some only make sense in conjunction with other fields.

58 * This is usually set by a USB_DEVICE_*() macro, which sets all

59 * other fields in this structure except for driver_info.

60 * @idVendor: USB vendor ID for a device; numbers are assigned

61 * by the USB forum to its members.

62 * @idProduct: Vendor-assigned product ID.

63 * @bcdDevice_lo: Low end of range of vendor-assigned product version

numbers.

64 * This is also used to identify individual product versions, for

65 * a range consisting of a single device.

66 * @bcdDevice_hi: High end of version number range. The range of product

67 * versions is inclusive.

68 * @bDeviceClass: Class of device; numbers are assigned

69 * by the USB forum. Products may choose to implement classes,

70 * or be vendor-specific. Device classes specify behavior of all

71 * the interfaces on a devices.

72 * @bDeviceSubClass: Subclass of device; associated with bDeviceClass.

73 * @bDeviceProtocol: Protocol of device; associated with bDeviceClass.

74 * @bInterfaceClass: Class of interface; numbers are assigned

75 * by the USB forum. Products may choose to implement classes,

76 * or be vendor-specific. Interface classes specify behavior only

77 * of a given interface; other interfaces may support other classes.

78 * @bInterfaceSubClass: Subclass of interface; associated with bInterfaceClass.

79 * @bInterfaceProtocol: Protocol of interface; associated with bInterfaceClass.

80 * @driver_info: Holds information used by the driver. Usually it holds

81 * a pointer to a descriptor understood by the driver, or perhaps

82 * device flags.

83 *

84 * In most cases, drivers will create a table of device IDs by using

85 * USB_DEVICE(), or similar macros designed for that purpose.

86 * They will then export it to userspace using MODULE_DEVICE_TABLE(),

87 * and provide it to the USB core through their usb_driver structure.

88 *

89 * See the usb_match_id() function for information about how matches are

90 * performed. Briefly, you will normally use one of several macros to help

91 * construct these entries. Each entry you provide will either identify

92 * one or more specific products, or will identify a class of products

93 * which have agreed to behave the same. You should put the more specific

94 * matches towards the beginning of your table, so that driver_info can

95 * record quirks of specific products.

96 */

97 struct usb_device_id {

98 /* which fields to match against? */

99 __u16 match_flags;

100

101 /* Used for product specific matches; range is inclusive */

102 __u16 idVendor;

103 __u16 idProduct;

104 __u16 bcdDevice_lo;

105 __u16 bcdDevice_hi;

106

107 /* Used for device class matches */

108 __u8 bDeviceClass;

109 __u8 bDeviceSubClass;

110 __u8 bDeviceProtocol;

111

112 /* Used for interface class matches */

113 __u8 bInterfaceClass;

114 __u8 bInterfaceSubClass;

115 __u8 bInterfaceProtocol;

116

117 /* not matched against */

118 kernel_ulong_t driver_info;

119 };

实际上这个结构体对每一个 usb设备来说,就相当于是她的身份证,记录了她的一些基本信息,通常我们的身

份证上会记录我们的姓名,性别,出生年月,户口地址等等,而 usb 设备她也有她需要记录的信息,以区分她和

别的 usb 设备,比如 Vendor-厂家,Product-产品,以及其他一些比如产品编号,产品的类别,遵循的协议,这

些都会在 usb 的规范里边找到对应的冬冬.暂且先不细说.

于是我们知道,一个 usb_driver 会把它的这张 id 表去和每一个 usb 设备的实际情况进行比较,如果该设备

的实际情况和这张表里的某一个 id相同,准确地说,只有这许多特征都吻合,才能够把一个 usb device 和这

个 usb driver 进行绑定,这些特征哪怕差一点也不行.就像我们每个人都是一道弧,都在不停寻找能让彼此

嵌成完整的圆的另一道弧,事实却是,每个人对∏(PI)的理解不尽相同,而圆心能否重合,或许只有痛过才知

道.差之毫厘,失之交臂.

那么 usb 设备的实际情况是什么时候建立起来的?嗯,在介绍.probe 指针之前有必要先谈一谈另一个数据

结构了,她就是 struct usb_device.

从协议中来,到协议中去(上)

在 struct usb_driver 中,.probe 和.disconnect 的原型如下:

int (*probe) (struct usb_interface *intf,const struct usb_device_id *id);

void (*disconnect) (struct usb_interface *intf);

我们来看其中的参数,struct usb_device_id 这个不用说了,刚才已经介绍过,那么 struct usb_interface

从何而来?还是让我们先从 struct usb_device 说起.

我们知道每一个 device 对应一个 struct device 结构体变量,但是 device 不可能是万能的,生命是多样性

的,就像我们可以用"人"来统称全人类,但是分的细一点,又有男人和女人的区别,那么 device 也一样,由于

有各种各样的设备,于是又出来了更多的词汇(数据结构),比如针对 usb 设备,开发者们设计了一个叫做

struct usb_device 的结构体.她定义于 include/linux/usb.h,

294 /*

295 * struct usb_device - kernel's representation of a USB device

296 *

297 * FIXME: Write the kerneldoc!

298 *

299 * Usbcore drivers should not set usbdev->state directly. Instead use

300 * usb_set_device_state().

301 */

302 struct usb_device {

303 int devnum; /* Address on USB bus */

304 char devpath [16]; /* Use in messages: /port/port/... */

305 enum usb_device_state state; /* configured, not attached, etc */

306 enum usb_device_speed speed; /* high/full/low (or error) */

307

308 struct usb_tt *tt; /* low/full speed dev, highspeed hub */

309 int ttport; /* device port on that tt hub */

310

311 struct semaphore serialize;

312

313 unsigned int toggle[2]; /* one bit for each endpoint ([0] = IN, [1] =

OUT) */

314 int epmaxpacketin[16]; /* INput endpoint specific maximums */

315 int epmaxpacketout[16]; /* OUTput endpoint specific maximums

316

317 struct usb_device *parent; /* our hub, unless we're the root */

318 struct usb_bus *bus; /* Bus we're part of */

319

320 struct device dev; /* Generic device interface */

321

322 struct usb_device_descriptor descriptor;/* Descriptor */

323 struct usb_host_config *config; /* All of the configs */

324 struct usb_host_config *actconfig;/* the active configuration */

325

326 char **rawdescriptors; /* Raw descriptors for each config */

327

328 int have_langid; /* whether string_langid is valid yet */

329 int string_langid; /* language ID for strings */

330

331 void *hcpriv; /* Host Controller private data */

332

333 struct list_head filelist;

334 struct dentry *usbfs_dentry; /* usbfs dentry entry for the device */

335

336 /*

337 * Child devices - these can be either new devices

338 * (if this is a hub device), or different instances

339 * of this same device.

340 *

341 * Each instance needs its own set of data structures.

342 */

343

344 int maxchild; /* Number of ports if hub */

345 struct usb_device *children[USB_MAXCHILDREN];

346 };

347 #define to_usb_device(d) container_of(d, struct usb_device, dev)

看起来很复杂的一个数据结构,不过我们目前不需要去理解她的每一个成员,不过我们可以看到,其中有一个

成员 struct device dev,没错,这就是前面说的那个属于每个设备的 struct device 结构体变量.

实际上,U 盘驱动里边并不会直接去处理这个结构体,因为对于一个 U 盘来说,她就是对应这么一个 struct

usb_device 的变量,这个变量由 usb core 负责申请和赋值.但是我们需要记住这个结构体变量,因为日后

我们调用 usb core 提供的函数的时候,会把这个变量作为参数传递上去,因为很简单,要和 usb core 交流,

总得让人家知道我们是谁吧,比如后来要调用的一个函数,usb_buffer_alloc,它就需要这个参数.

而对 U 盘设备驱动来说,比这个 struct usb_device 更重要的数据结构是,struct usb_interface.走到这

一步,我们不得不去了解一点 usb 设备的规范了,或者专业一点说,usb 协议.因为我们至少要知道什么是

usb interface.

从协议中来,到协议中去(中)

星爷说,人有人他妈,妖有妖他妈.说的就是任何事物都有其要遵守的规矩.usb 设备要遵循的就是 usb 协

议. 不管是软件还是硬件,在设计的伊始,总是要参考 usb协议.怎么设计硬件,如何编写软件,不看 usb协议,

谁也不可能凭空想象出来.毕竟不是写小说,有几人能像海岩那样,光凭想象就能写出便衣警察,永不瞑目,玉

观音这些经典的爱情加案情的作品来呢.

剩余200页未读，继续阅读

lwqx543

粉丝: 1
资源: 3

Linux U盘深度解析：技术内幕与驱动机制

Linux USB探索：从总线到驱动的深度解析

Linux USB探索之旅：从总线到设备驱动

Linux USB驱动探索：《Linux那些事儿之我是U盘》精华解读

linux那些事儿之我是USB.zip

linux那些事儿我是USB.pdf

linux那些事儿之我是U盘

Linux那些事儿之我是XXX全集.rar

Linux那些事儿之我是USB（第2版）

Linux那些事儿.rar

Linux那些事儿之全集

最新资源