Linux内核工程导论——存储：USB

kernel USB驱动层

         首先USB（UniversalSerial Bus）是一种传输协议，并不是一种数据协议，也没有任何语义上的指令意义。USB传输协议所传输的SCSI命令才是各个存储设备所能理解的命令，USB的责任就是将这些命令送达并且返回命令所要求的数据。所以，USB传输协议是不认识SCSI指令的，它的任务只是将上层的任何数据以USB的传输方式送达。

USB背景知识

         USB作为一种传输协议，主要有三个优点：集成电源、造价便宜、支持广泛。这里要说明的是，论速度USB不算最快；论便宜，USB不算最便宜；USB软件支持系统的复杂性，在所有的传输协议里首屈一指的复杂。但是USB依然被广泛的应用，以致成为全世界的事实数据标准，就连Intel和苹果共同推广的速度极高的thunderbird传输协议也无法撼动USB的地位，内部的原因主要有两个：集成电源和支持广泛。集成电源让其不仅可以作为数据接口，也可以作为充电接口存在，在移动设备的充电方式上，USB口已经成为了事实上标准。支持广泛上，USB可能并不是因为好所以才被广泛支持的，而是因为有广泛的大商家支持，所以才发展的如此顺利。Intel、IBM、Microsoft、compaq等一干具有影响力的大型公司就是USB的创始者。

         USB是金字塔型的，与SCSI一样，最上层是总线的硬件控制器芯片：USB host，约定的，根host下必须挂一个hub。USB hub的存在让USB系统组成一颗树，可以自由的扩展。  

 

         图：USB金字塔图

USB传输方式

         那究竟什么是USB的传输方式呢？USB分为1.0，1.1，2.0，3.0和3.1几个版本。

USB子系统上层（USB设备驱动层）

作为模块的USB storage

         USB子系统的上层就是实际的驱动程序，是要注册到系统的驱动程序列表的结构体。对storage来说，在drivers/usb/storage/usb.c中有完整的模块初始化和卸载函数。

USB与SCSI的对接

         USB的每个设备实际上都是SCSI的一个scsi host，所以scsi向USB传递命令都是直接通过调用这个scsi host所规定的接口函数。最重要的是queuecommand函数，这个函数将从scsi传来的命令实际挂载到USB子系统内部的结构体，也是USB的最上层结构体（struct us_data）。值得注意的是，这个queuecommand的函数接口虽然是在scsi子系统定义的，但是在USB子系统中其具体的实现却是在USB子系统中。通过这一步USB子系统将来自scsi层的命令传输到了本层。但是，这时，该命令仍然没有执行。

         另外，每个us_data同时只能有一个命令，如果当前us_data已经有命令了，queuecommand将返回错误。us_data是USB子系统上层调度的实体，并不代表任何的具体设备。

         而，这个us_data是如何与scsi host关联起来的呢？在Scsi_Host结构体的最下面，有一个域叫做unsigned long hostdata[0]。整个us_data结构体就是放在这里的，所以可以通过Scsi_Host直接找到其对应的us_data，也就是唯一的USB设备。

         如果阅读代码会发现，在scsiglue.c中定义scsi的接口数据结构并不是直接定义的Scsi_Host，而是定义的struct scsi_host_template。这是SCSI的结构决定的，只需要定义这个，SCSI子系统会根据这个生成对应的Scsi_Host结构体。

USB存储设备的种类

 

USB Storage执行SCSI命令

         这里以USBStorage为例讲述。USB设备被关注最多的就是存储设备，USB的存储设备在USB子系统中位于drivers/usb/storage子目录。

真正执行us_data中命令的是usb-storage内核线程。该线程可以有多个，其启动的参数就是传入一个us_data。

         该线程会做一些列检查，例如当前是否有命令，没有的话退出。最主要的，检测有命令要执行时，调用us_data结构体中注册的函数proto_handler执行。

         从这里可以看出linux内核的数据结构为核心的设计思想。所有的操作和操作所需要的数据都是数据结构中，但是什么时候调用这些操作，调用操作的结果怎么存储到数据结构中，则是通过一些外部的函数或线程进行的。所有的代码都围绕着数据结构为其打工，周边代码存在的目的是让数据结构动起来。

         那proto_handler究竟调用的什么呢？USB子系统的存储部分根据SC（subclass）类型不同定义了不同的proto_handler。

#define US_SC_RBC         0x01          /* Typically, flash devices */

#define US_SC_8020        0x02          /* CD-ROM */

#define US_SC_QIC         0x03          /* QIC-157 Tapes */

#define US_SC_UFI    0x04           /* Floppy */

#define US_SC_8070        0x05          /* Removable media */

#define US_SC_SCSI         0x06          /* Transparent */

#define US_SC_LOCKABLE       0x07          /* Password-protected */

 

#define US_SC_ISD200    0xf0               /* ISD200 ATA */

#define US_SC_CYP_ATACB  0xf1           /* Cypress ATACB */

#define US_SC_DEVICE   0xff                   /* Use device's value */

         实际上，虽然分类了这么多，但是处理函数只有两种可能。是多对一的关系。最终实际上调用的函数us_data结构体的注册函数：transport。

         实际的transport根据协议不同还有两个函数（但是有三种USB协议）

#define US_PR_CBI 0x00          /* Control/Bulk/Interrupt */

#define US_PR_CB  0x01          /* Control/Bulk w/o interrupt */

#define US_PR_BULK       0x50          /* bulk only */

         但是原理都是一致的，生成并填充一个urb，然后提交。URB是USB core（USB总线驱动）中的内容。稍后再讨论。对于磁盘等存储设备，对应的是US_PR_BULK模式。

US_PR_BULK模式

         首先要介绍USB会向设备发送的三种命令：CBW（CommandBlock Wrapper）、CSW（Command Status Wrapper）和数据。

         无论如何，其都会首先发送CBW，只有在有数据的时候才会发送数据体。最后再发送CSW获得设备的命令执行情况。最后根据CSW返回的设备情况向上报告当前命令的执行是否成功。

         可以看出，这是一个损耗很高的过程，所以当发送数据时应尽量发送多的数据。实际的发送代码位于drivers/usb/storage/transport.c中。

 

         这里，我们忽然想到，是否可以让其发送多次CBW而只获得一次CSW？从而理论上就可以大幅度的提高速度。

USB Storage设备发现过程

         当这个驱动扫描函数被调用时(storage_probe)，就会进行扫描发现过程。值得注意的是这里的设备首先也是一个scsi设备，所以扫描完毕需要调用让scsi子系统也针对此设备进行扫描和数据填充。

storage_probe包括usb_stor_probe1，usb_stor_probe2两个阶段，完成对scsi_host为USB storage的us_data初始化时。在usb_stor_probe2末尾时还会启动另外一个内核线程usb-stor-scan。这个内核线程会实际调用scsi的扫描接口，填充scsi_host的其他域。这里为何使用的是线程来？是延迟的一种手段，不让内核在这里阻塞，对scsi部分内容的填充可以后续完成。

实现一个非SCSI直接调用USB storage接口的函数

分析第一步：从哪里入手

综上可知，一个USB子系统与SCSI层的对接靠的是scsiglue.c文件中的函数，其主要是实现了queuecommand函数。所以我们要做的是直接生成一个struct scsi_cmnd结构体，插入到对应的struct us_data的srb中。

首先，我们要搞清楚scsiglue中有多少USB相关的操作被挂接到了scsi上。真正的函数执行有6个：

queuecommand：将SCSICommand放入USB队列

         command_abort：取消在USB队列中的ScsiCommand

device_reset： 设备复位时候调用的复位函数

bus_reset：总线复位时调用的复位函数

slave_alloc：发现设备时，最早调用的函数，用来为设备的生成提前分配设备驱动相关的内存

slave_configure：发现设备结束后，调用该函数进行最后的设备相关的配置

综上，可以看出，这6个函数中，其他5个都可以直接不动的让scsi使用，我们要做的就是让scsiqueuecommand与USB相关的断开，而使用我们的。甚至也不必要断开，只要两个不发生冲突就可以了。

我们的方案应该让原来的SCSi也发挥作用，如此，就算我们的路径不工作，scsi路径也可以正常驱动USB工作。所以我们要另外写一个函数调用USB的queuecommand函数即可，而这个函数的处理一个scsi command之外，还需要一个回调函数，用来通知命令的执行结果。

所以，问题的关键是如何构造scsicommand以及提供一个回调函数。

分析第二步：构造scsi command

由于SCSI command有很多域，但并不是所有的域都被USB子系统所利用。追踪USB的代码，可以发现，其有用的域有如下几个：

 

struct scsi_cmnd {

         struct scsi_device *device; //代表SCSI设备，对于USB来说，能够通过它获得其最末尾的us_data，并且要使用其一些域进行从属判断，所以可以直接使用系统原有的。

         struct list_head list;  /* scsi_cmnd participates in queue lists */

         struct list_head eh_entry; /* entry for the host eh_cmd_q */

         int eh_eflags;            /* Used by error handlr */

 

         /*

          * A SCSI Command is assigned a nonzero serial_number before passed

          * to the driver's queue command function.  The serial_number is

          * cleared when scsi_done is entered indicating that the command

          * has been completed.  It is a bug for LLDDs to use this number

          * for purposes other than printk (and even that is only useful

          * for debugging).

          */

         unsigned long serial_number;

 

         /*

          * This is set to jiffies as it was when the command was first

          * allocated.  It is used to time how long the command has

          * been outstanding

          */

         unsigned long jiffies_at_alloc;

 

         int retries;

         int allowed;

 

         unsigned char prot_op;

         unsigned char prot_type;

 

        

         enum dma_data_direction sc_data_direction;//表示数据的流向（从总线到设备还是从设备到总线）

 

         unsigned short cmd_len;  //要发送的命令的长度（指的是cmnd所指向的长度，并非数据体的长度）

         unsigned char *cmnd;  //实际的要执行的命令类型

         struct scsi_data_buffer sdb;  //实际命令的体，这也是我们要构造的主体。可以存在只有数据的命令，叫bulk传输。如果没有命令头，而使用的是bulk传输，就没有命令头的开销。这个域的长度也包含在这个结构体中。

         struct scsi_data_buffer *prot_sdb;

 

         unsigned underflow;        /* Return error if less than

                                        this amount is transferred */

 

         unsigned transfersize;     /* How much we are guaranteed to

                                        transfer with each SCSI transfer

                                        (ie, between disconnect /

                                        reconnects.   Probably == sector

                                        size */

 

         struct request *request; /* The command we are

                                             working on */

 

#define SCSI_SENSE_BUFFERSIZE 96

         unsigned char *sense_buffer;  //这是一种sense功能

         void (*scsi_done) (struct scsi_cmnd *);   //命令完成后调用的函数，我们可以将其截断成我们自己的发送处理函数

 

         /*

          * The following fields can be written to by the host specific code.

          * Everything else should be left alone.

          */

         struct scsi_pointer SCp;  /* Scratchpad used by some host adapters */

 

         unsigned char *host_scribble;         /* The host adapter is allowed to

                                                * call scsi_malloc and get some memory

                                                * and hang it here.  The host adapter

                                                * is also expected to call scsi_free

                                                * to release this memory.  (The memory

                                                * obtained by scsi_malloc is guaranteed

                                                * to be at an address < 16Mb). */

 

         int result;          //本条命令的处理结果（一系列预定义的宏）

         unsigned char tag;  /* SCSI-II queued command tag */

};

         由于usb-storage线程的运行时要传入一个us_data结构体，这个结构体和其要处理的command的device域的最下面的结构体应该是同一个，所以我们要利用该us_data。

         由于在usb-storage中有对scsi host的锁。所以，我们在处理我们的scsi command的时候，同时也制止了本设备下发命令，这正好是我们所希望看到的。

         构造scsi命令可以参考scsi驱动中的做法，在sd.c中可以找到相关的代码。

分析第三步

 

USB子系统的中层（USB core）

USB子系统的下层

设备识别过程

         首先，无论这个设备是存储设备还是打印机等设备。最先经过的都是core/hub.c。我们从一个不是最底层的函数开始，再逐步深入。

         hub.c的入口函数是hub_thread线程函数，该函数循环调用hub_events函数处理hub事件，我们暂时不关心事件是如何产生，只关心如何处理。

         hub_events中可以处理很多事件，与设备识别过程相关的最重要的是hub_port_connect_change函数，用于处理端口的逻辑连接或者物理连接发生变化的情况。