Scsi - Index of

雨,总是在最纤细的时候飘逸;
花,总是在将调零的时候让人惋惜;
夜,总是在最深冷的时候令人希冀;
在编写Linux 设备驱动时,在生与死的抉择中,我们总是无法逃避,我们总是要涉及内存管理.内存管理毫
无疑问是Linux 内核中最复杂的一部分,能不涉及我们都希望别去涉及.但生活中总是充满了无奈,该来的
还
是会来.而我们倒是该庆幸,毕竟它不是每个月来一次.(这里说的是水电煤气费的单子,不许误解.)更不是八
点档的连续剧,每天准时来赚你的眼泪.
所以,usb_stor_access_xfer_buf()函数映入了人们的眼帘.
首先判断srb->use_sg 是否为0.
无聊的it 玩家们创建了有一个词,叫做scatter/gather,她是一种用于高性能IO 的标准技术.她通常意味
着一种DMA 传输方式,对于一个给定的数据块,她老人家可能在内存中存在于一些离散的缓冲区,换言之,
就
是说一些不连续的内存缓冲区一起保存一个数据块,如果没有scatter/gather 呢,那么当我们要建立一个
从内存到磁盘的传输,那么操作系统通常会为每一个buffer 做一次传输,或者干脆就是把这些不连续的
buffer 里边的冬冬全都移动到另一个很大的buffer 里边,然后再开始传输.那么这两种方法显然都是效率
不
高的.毫无疑问,如果 操作系统/驱动程序/硬件 能够把这些来自内存中离散位置的数据收集起来(gather
up)并转移她们到适当位置整个这个步骤是一个单一的操作的话,效率肯定就会更高.反之,如果要从磁盘向
内存中传输,而有一个单一的操作能够把数据块直接分散开来(scatter)到达内存中需要的位置,而不再需要
中间的那个块移动,或者别的方法,那么显然,效率总会更高.
在struct scsi_cmnd 中,有一个成员unsigned short use_sg,上头传下来的scsi_cmnd,其use_sg
是设好了的,咱们判断一下,如果她为0,那么说明没有使用scatter/gather.struct scsi_cmnd 中还有两个
成员,unsigned request_bufflen 和void *request_buffer,她们和use_sg 是什么关系呢?
事实上,要玩scatter/gather,就需要一个scatterlist 数组,有人管她叫散列表数组.对于不同的硬件平台,
定义了不同的struct scatterlist 结构体,她们来自include/asm/scatterlist.h 中,(如果是硬件平台i386
的,那么就是include/asm-i386/scatterlist.h,如果是x86_64 的平台,那么就在
include/asm-x86_64/scatterlist.h 中),然后所谓的scatter/gather 就是一次把整个scatterlist 数组
给传送掉.而use_sg 为0 就表示没有scatter gather list,或者说scatterlist,对于这种情况,数据将直接
传送给request_buffer 或者直接从request_buffer 中取得数据.而如果use_sg 大于0,那么表示
scatter gather list 这么一个数组就在request_buffer 中,而数组元素个数正是use_sg 个.也就是
说,srb->request_buffer 里边的冬冬有两种可能,一种是包含了数据本身,另一种是包含了scatter
gather list.具体是哪种情况通过判断use_sg 来决定.而接下来即将要讲到的srb->request_bufflen 顾
135
名思义,就是buffer 的长度,但对于use_sg 大于0 的情况,换言之,对于使用scatter gather list 的情
况,request_bufflen 没有意义,将被忽略.
对这些原理有了基本的了解之后,我们可以从下节开始看代码了.这里先提醒一下,要注意我们这个函数虽
然看似是传输数据,可它实际上并没有和usb 真正发生关系,我们只是从软件上来fix 一个硬件的bug,这个
bug 就是我们已经说过了的,不能响应基本的SCSI 命令INQUIRY,你问她,她完全不予理睬.至于为什么
不
能响应我就不用说了吧?人的冷漠,不是因为天生就如此,只是暗淡的心境早已将所有通向阳光的窗户关闭
了.而设备的冷漠,显然是制造商做的傻事了.(我没有讽刺Sony 的意思,事实上这种情况并非只有Sony 他
们家才出现了,别的厂家也有这样的产品.只是,Device 有bug,可以让程序去补,我们80 后的梦碎了,拿什
么去补?)