I'm USB in Linux, I'm a USB flash drive (30) TheEnd)

After the INQUIRY problem is solved, we can continue to go down to the second line. this is the real place for batch transmission. proto_handler () is the function pointer for processing the SCSI command. All the code before usb_stor_control_thread is used to determine whether there is...

 

After the INQUIRY problem is solved, we can continue to go down to the second line. this is the real place for batch transmission. proto_handler () is the function pointer for processing the SCSI command. All the code before usb_stor_control_thread is used to determine whether it is necessary to call the proto_handler () function. for example, if it times out, for example, the module should be uninstalled, for example, if it is set to disconnect the flag, for example, if you want to handle the problematic INQUIRY and so on, you need to exclude these situations before it is necessary to arrive here to execute the real command. In fact, this is to control it from a macro perspective to ensure that we are taking the right path, rather than taking the wrong path for half a day. After all, running is useless on the wrong road!

 

We don't have to rush to proto_handler to see it first, but read the code outside. When we were young, we thought that the world outside was wonderful? We will skip proto_handler () and read the remaining code in usb_stor_control_thread () to fully understand how the daemon loops.

 

Line 3: as long as the result of the preceding command is that the result of the port-> result is not DID_ABORT, the command is successfully executed. So we call the scsi_done function.

 

Row 390, SkipForAbort, is a row flag that corresponds to the previous goto SkipForAbort statement. To continue, row 3 and the preceding comments are also quite clear. if us_f1_x_timed_out is set, the process with this flag is actually wakened by command_abort, we will talk about command_abort () later (). The reason why we judge this flag is not to judge it. The result = DID_ABORT comment is also clear, because it may be the abort command received after the usb transmission is complete. In other words, even if the result of your server load balancer-> is not DID_ABORT, you may receive the abort request again. Therefore, you must set a flag to determine whether the abort request is correct.

 

Line 3: If you want to disconnect, run a command, or run abort, you can leave us-> server load balancer empty. We have already said the two locks in the remaining two rows, which will be unified at the end.

 

Line 3. now, this daemon process goes through again, and the for loop continues.

 

Finally, there is only 431 rows left. the execution of the program to this row means that the for loop is over. from the code of the for loop, we can easily see that there is only one sentence to end the for loop, that is, break. As mentioned above, it means that the module will be uninstalled. So here complete_and_exit () is to wake up others and end themselves at the same time, so at this moment, usb_stor_control_thread () will officially end, maybe for it, the end is the relief.

 

We have finally finished talking about this daemon, and the proto_handler () function is the two lines. because of their importance, we can pick them out separately.