解决了这个INQUIRY的问题,我们就可以继续往下走了,373行,这就是真正的Bulk传输的地方,proto_handler()就是正儿八经的处理SCSI命令的函数指针.而usb_stor_control_thread之前的所有代码就是为了判断是不是有必要调用proto_handler(),比如超时了,比如模块该卸载了,比如设置了断开flag了,比如要处理的就是这个有问题的INQUIRY,等等这些情况都需要先排除了才有必要到达这里来执行真正的命令.实际上这就是先从宏观上来控制,保证我们走的是一条正确的道路,而不至于是沿着错误的道路走半天,毕竟,在错误的路上,就算奔跑也没有用!别说奔跑了,裸奔也没有用!
我们倒是先不急着到proto_handler里边去看,先把外边的代码看完.小时候,我们不都天真的以为,外面的世界很精彩么?我们先跳过proto_handler(),把usb_stor_control_thread()中剩下的代码看完,从而完整的了解这个守护进程究竟是如何循环的.
382行,只要刚才的命令的结果即srb->result不为DID_ABORT,那么就是成功执行了.于是我们就调用scsi_done函数.
387行,SkipForAbort,就是一个行标志,对应前面的那个goto SkipForAbort语句. 记得大学期间,学到谭浩强大哥那本书中goto的时候,老师总是会告诫大家,不要乱用goto语句,这是不好的编程习惯,不过在Linux内核源代码中,goto语句却是比比皆是,真让人为这些写Linux源代码的同志们的C语言水平担心啊,肯定在校期间没有好好念书,辜负了家长殷切的期望啊.算了,不说他们了,这些家伙少年不识愁滋味.我们 继续说Linux,396行,前面的注释也说得很清楚了,如果是设置了US_FLIDX_TIMED_OUT那么就唤醒设这个flag的进程,其实就是唤醒command_abort,后面我们会讲command_abort().这里之所以判断这个flag而不是判断srb->result==DID_ABORT注释里说得也很清楚,因为有可能是在usb传输结束之后才收到的abort命令,换言之,即便你的srb->result不为DID_ABORT也可能最新又接到了abort的请求,所以这里就判断abort请求必然要设置的一个flag来判断.
400行,SkipForDisconnect,这也没啥说的,和前面的goto SkipForDisconnect语句对应,如果要断开了,或者是一个命令执行完了,或者是abort了,那么最终就是把us->srb给置空.剩下两行的两把锁我们已经说过,会到最后统一来讲.
406行,至此,这个守护进程就算是走了一遍了,for循环继续,就像彼岸花,开一千年,落一千年,花叶永不相见.情不为因果,缘注定生死.不仅仅是曼珠和沙华一次次的跌入诅咒的轮回,其实世间万事万物都是轮回的,包括痛苦.
最后的最后,只剩下422这一行了,程序执行到这一行意味着for循环结束了,而从for循环的代码我们不难看出,结束for循环的只有一句话,就是那句break,我们前面说过,它意味着模块要被卸载了.所以这里complete_and_exit()就是唤醒别人同时结束自己,于是这一刻,usb_stor_control_thread()也就正式结束了,也许对她来说,结束就是解脱吧.此情可待成追忆,只是当时已惘然.
需要解释一下的是,complete_and_exit()这里唤醒的是谁?是usb_stor_release_resources(),为什么要唤醒,我们稍候讲到这个函数的时候再来看.而关于这个守护进程,我们也终于讲完了,其中的proto_handler()这两行,因为其重要性,我们单独挑出来讲.