Scsi - Index of

usb_stor_acquire_resources()函数往下走,kernel_thread()函数对于父进程而言返回的是子进程的
进程id,所以802 行先判断,若是返回值p 小于0,则说明出错了,否则,那就把p 赋给us 的元素pid.
于是,咱们接下来必须再次兵分两路,分别跟踪父进程和子进程前进了.先看父进程,810 行,执行
wait_for_completion(&(us->notify)),如果您说wait_for_completion 是谁?您早已经把她忘怀,那么
她会很伤心的.记得咱们当初在提交urb 的时候调用过她吗?咱们初始化了一个等待队列,urb->done,然
后
咱们提交了urb,然后咱们通过调用wait_for_completion(&urb->done)进入了等待,进入了睡眠,当urb
被usb core 处理完了,或者说被urb host controller 处理完了,complete()函数将会被调用,从而唤醒咱
们那个进入睡眠的进程.所以此处也一样,us->notify 是在很早很早以前storage_probe()函数中初始化
的,该函数的945 行,init_completion(&(us->notify)),而struct us_data 中,有这么一个元素notify,
是struct completion 结构体变量,所以在这里,父进程将进入睡眠,谁来唤醒他?没错,您很聪明,正是子进
109
程,也正是在usb_stor_control_thread()函数中,会有complete(&(us->notify))这么一
句,wait_for_completion()和complete()是一对青梅竹马的函数,她们总是一起被用,一个设置进程进入
睡眠,另一个则负责把这个进入睡眠的进程唤醒,如果您知道信号量的话,她们就类似于信号量中的
down()/up()函数对,只不过她们更加安全.
好,父进程先搁一搁,反正他进入睡眠了,没人唤醒他的话,他是不会往下走的.来看子进程,也就是
usb_stor_control_thread()函数,这个函数定义于drivers/usb/storage/usb.c 中.咱们下一节再深入
这个函数,现在,休息,休息一会...
彼岸花的传说(二)
如果让观众短信投票的话,usb_stor_control_thread()这个函数中的代码无疑是整个模块中最为精华
的代码.我们只需要它中间301 行那个for(;;)就知道,这是一个死循环,即使别的代码都执行完了,即使别的
函数都退出了,这个函数仍然像永不消逝的电波一般,经典常驻.显然,只有死循环才能代码永恒.才能代表忠
诚.这是每一个守护者的职责.
usb_stor_control_thread(),其代码如下:
281 static int usb_stor_control_thread(void * __us)
282 {
283 struct us_data *us = (struct us_data *)__us;
284 struct Scsi_Host *host = us->host;
285
286 lock_kernel();
287
288 /*
289 * This thread doesn't need any user-level access,
290 * so get rid of all our resources.
291 */
292 daemonize("usb-storage");
293
294 current->flags |= PF_NOFREEZE;
295
296 unlock_kernel();
297