分类： LINUX
2012-03-30 14:26:41
解决了这个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()这两行，因为其重要性，我们单独挑出来讲。
