《Linux那些事儿之我是USB》我是U盘(30)彼岸花的传说(The End)

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/fudan_abc/article/details/7024700

解决了这个INQUIRY的问题,我们就可以继续往下走了,372行,这就是真正的批量传输的地方,proto_handler()就是正儿八经的处理SCSI命令的函数指针。而usb_stor_control_thread之前的所有代码就是为了判断是不是有必要调用函数proto_handler(),比如超时了,比如模块该卸载了,比如设置断开flag了,比如要处理的就是这个有问题的INQUIRY等,这些情况都需要先排除了才有必要到达这里来执行真正的命令。实际上这就是先从宏观上来控制,保证我们走的是一条正确的道路,而不至于是沿着错误的道路走半天。毕竟,在错误的路上,就算奔跑也没有用!

我们倒是先不急着到proto_handler里边去看,先把外边的代码看完。小时候,我们不都天真地以为,外面的世界很精彩吗?我们先跳过proto_handler(),把usb_stor_control_thread()中剩下的代码看完,从而完整地了解这个守护进程究竟是如何循环的。

385行,只要刚才的命令的结果即srb->result不为DID_ABORT,那么就是成功执行了。于是我们就调用scsi_done函数。

390行,SkipForAbort,就是一个行标志,对应前面的goto SkipForAbort语句。继续说,399行,前面的注释也说得很清楚了,如果是设置了US_FLIDX_TIMED_OUT那么就唤醒设这个flag的进程,其实就是唤醒command_abort,后面我们会讲command_abort()。这里之所以判断这个flag而不是判断srb->result==DID_ABORT注释里说得也很清楚,因为有可能是在usb传输结束之后才收到的abort命令,换言之,即便你的srb->result不为DID_ABORT也可能最新又接到了abort的请求,所以这里就判断abort请求必然要设置的一个flag来判断。

408行,如果要断开了,或者是一个命令执行完了,或者是abort了,那么最终就是把us->srb置空。剩下两行的两把锁我们已经说过,会到最后统一讲。

413行,至此,这个守护进程就算是走了一遍,for循环继续。

最后,只剩下431这行了,程序执行到这一行意味着for循环结束了,而从for循环的代码我们不难看出,结束for循环的只有一句话,就是break。前面说过,它意味着模块要被卸载了。所以这里complete_and_exit()就是唤醒别人同时结束自己,于是这一刻,usb_stor_control_thread()也就正式结束了,也许对它来说,结束就是解脱吧。

关于这个守护进程,我们也终于讲完了,其中的函数proto_handler()这两行,因为其重要性,我们单独挑出来讲。


展开阅读全文

没有更多推荐了,返回首页