3-9xxx驱动程序分析.docx

3w-9xxx驱动程序分析3w-9xxx驱动程序包括3w-9xxx.h头文件和3w-9xxx.c主C程序，是AMCC公司3ware 9000 Storage Controller device（RAID卡系列）的驱动程序。在源文件的开头的注释中这样写的：3w-9xxx.h -- 3ware 9000 Storage Controller device driver for Linux.3w-9xxx.c -- 3ware 9000 Storage Controller device driver for Linux.3ware 9000 Storage Controller device是一种PCI接口的RAID卡，因此，这个驱动程序本质上是一个PCI驱动程序。该PCI RAID卡后面接的是SCSI磁盘，走的是SCSI这套协议。我们知道，操作系统中SCSI子系统可以分为3层，分别是SCSI高层、SCSI中间层和SCSI底层。SCSI高层对应具体的块设备驱动，如磁盘驱动（sd.c），光盘驱动(sr.c)等。在这层中，需要支持设备要求支持的SCSI命令（虽然SCSI协议SBC中为块设备定义了统一的命令集，但是针对各种不同的块设备如磁盘、光盘等，还可以定义自己的命令），将块设备注册到块操作系统子系统中也是在该层完成的。SCSI提供一些公共的函数，包括错误处理和恢复，SCSI总线扫描等。SCSI底层是最底层的驱动程序，和硬件设备直接打交道来控制设备，因此和硬件设备的接口有关。比如我们这里是一个PCI的RAID卡，因此它是一个PCI驱动，位于SCSI 3层中的底层。该层需要初始化上层的业务逻辑，并将上层的命令发送到设备上去，因此，该层需要知道硬件设备暴露给它的编程接口，也就是各种控制和状态寄存器、其他特定的寄存器等。下面根据我自己的理解，以读过程为例，简要的描述一下应用程序和硬件块设备之间进行数据交换的流程。首先，应用程序调用库函数fread或者直接调用read系统调用产生读请求，在这里读请求可以理解成需要从文件的某个偏移处读取多长的数据到用户的缓冲区中。上面的两个函数会调用sys_read进入到内核中，从这里开始进程在系统空间中运行。sys_read又会调用具体的文件系统注册的函数对请求进行处理，首先查看请求对应的数据是否在该文件的PAGE CACHE中存在，如果请求的数据已经在PAGE CACHE中，则直接将数据返回给用户空间的缓冲区中，这次请求结束。如果不再PAGE CACHE中，文件系统将经过处理后的请求封装成bio请求格式，发送到块层。bio请求包括读请求的逻辑扇区地址（LBA），读到内存的地址和长度（可能包含多个内存片段）。块层首先查看该bio请求是否能合并到请求队列的某个请求中，若能则合并请求，若不能则为该bio生成一个新的request请求经过重排序后加入到请求队列中。到这里，请求已经到了请求队列中，等待进一步的处理。操作系统的后台线程会定期（还有其他可能触发的条件）的从请求队列中取下请求交给SCSI子系统进行处理，包括调用SCSI上层的块设备驱动准备SCSI命令、准备用于DMA的聚散列表等，最后通过SCSI底层也就是底层驱动将命令发送到设备端。底层驱动往往是通过PIO的方式写设备端的寄存器将命令发送下去，或者将命令的地址写到设备的某个寄存器中，设备再通过DMA的方式从该地址把命令读下去。最终的结果是命令在设备端被解析、执行，然后设备将读取的数据通过DMA的方式写到主机端内核缓冲区或者直接到用户空间缓存（聚散DMA方式），并通过中断的方式通知主机请求执行完成。在中断服务程序中会唤醒之前在该数据上等待的进程继续执行。这样整个请求处理结束，fread或者read函数执行完成，应用程序继续往下执行。上面只是个人的理解，欢迎大家批评指正。之前自己了解了一下SCSI协议，还看了linux SCSI子系统相关的知识。我们知道，对于连接在PCI总线上的设备如显卡、网卡等（这里是PCI RAID卡），我们应该在PCI驱动的probe函数中初始化上层的业务逻辑，该RAID卡充当的是SCSI主机适配器的角色，我们在probe函数中要为该适配器分配Scsi_Host结构，并提供主机适配器模板（scsi_host_template），然后将Scsi_Host添加到SCSI子系统中，再调用scsi_scan_host扫描适配器后面的SCSI总线，将后面的SCSI设备添加到SCSI子系统中，这就是我们前面所指的业务逻辑。前面我们提到过，内核线程会定期从request_queue中把请求取出交给SCSI各层处理，最后通过调用queue_command函数将命令提交到底层驱动的命令队列中。我们知道，每个线程在提交了bio的请求后，bio对应的内存页或者