I am USB in Linux. I am a USB flash drive (24) Legend of the other side (3)

 

As mentioned above, return to the usb_stor_acquire_resources () function and return 0. So we finally went back to the storage_probe () function.

 

Row 3: The scsi_add_host () function is executed. The previously applied us-> host is passed to it as a parameter, and intf-> dev is also passed to it, this is used to register sysfs. As mentioned above, scsi_add_host () must be executed after scsi_host_alloc so that the SCSI core layer can know that such a host exists. If scsi_add_host () is successful, 0 is returned; otherwise, an error code is returned. If everything goes well, it will go to 1009 lines. Don't worry, just paste the code first. This is the last section of the storage_probe () function:

 

1014

 

1015/* Startup the thread for delayed SCSI-device scanning */

 

1016 th = kthread_create (usb_stor_scan_thread, us, "usb-stor-scan ");

 

1017 if (IS_ERR (th )){

 

1018 printk (KERN_WARNING USB_STORAGE

 

1019 "Unable to start the device-scanning thread \ n ");

 

1020 quiesce_and_remove_host (us );

 

1021 result = PTR_ERR (th );

 

1022 goto BadDevice;

 

1023}

 

1024

 

1025/* Take a reference to the hostfor the scanning thread and

 

1026 * count it among all the threads we have launched. Then

 

1027 * start it up .*/

 

1028 scsi_host_get (us_to_host (us ));

 

1029 atomic_inc (& total_threads );

 

1030 wake_up_process (th );

 

1031

 

1032 return 0;

 

1033

 

1034/* We come here if there are anyproble MS */

 

1035 BadDevice:

 

1036 US_DEBUGP ("storage_probe () failed \ n ");

 

1037 release_everything (s );

 

1038 return result;

 

1039}

 

Once again, we saw kthread_create, which does not need to be explained. Here we naturally create a kernel daemon, but this time it was usb_stor_scan_thread, and the last time it was usb_stor_control_thread. The usb_stor_scan_thread () function is also defined in drivers/usb/storage/usb. c:

 

904/* Thread to carry out delayed SCSI-devicescanning */

 

905 static int usb_stor_scan_thread (void * _ us)

 

906 {

 

907 structus_data * us = (struct us_data *) _ us;

 

908

 

909 printk (KERN_DEBUG

 

910 "usb-storage: device found at % d \ n", us-> pusb_dev-> devnum );

 

911

 

912/* Wait for the timeout to expire or for a disconnect */

 

913 if (delay_use> 0 ){

 

914 printk (KERN_DEBUG "usb-storage: waitingfor device"

 

915 "to settle before scanning \ n ");

 

916 retry:

 

917 wait_event_interruptible_timeout (us-> delay_wait,

 

918 test_bit (us_fw.x_disconnecting, & us-> flags ),

 

919 delay_use * HZ );

 

920 if (try_to_freeze ())

 

921 goto retry;

 

922}

 

923

 

924/* If the device is still connected, perform the scanning */

 

925 if (! Test_bit (us_fw.x_disconnecting, & us-> flags )){

 

926

 

927/* For bulk-only devices, determine the max LUN value */

 

928 if (us-> protocol = US_PR_BULK &&

 

929! (Us-> flags & US_FL_SINGLE_LUN )){

 

930 mutex_lock (& us-> dev_mutex );

 

931 us-> max_lun = usb_stor_Bulk_max_lun (us );

 

932 mutex_unlock (& us-> dev_mutex );

 

933}

 

934 scsi_scan_host (us_to_host (us ));

 

935 printk (KERN_DEBUG "usb-storage: devicescan complete \ n ");

 

936

 

937/* shocould we unbind if no devices weredetected? */

 

938}

 

939

 

940 scsi_host_put (us_to_host (us ));

 

941 complete_and_exit (& threads_gone, 0 );

 

942}

 

Row 3, where does delay_use come from? In the same file, a static variable is defined at the beginning:

 

110 static unsigned int delay_use = 5;

 

111 module_param (delay_use, uint, S_IRUGO | S_IWUSR );

 

112 MODULE_PARM_DESC (delay_use, "seconds todelay before using a new device ");

 

Set delay_use to 5, while module_param is a macro provided by Linux Kernel 2.6, so that delay_use can be set when the module is loaded. (If this parameter is not set, the value 5 indicates that a new device is waiting for a delay of 5 seconds .) Why latency? When the inserted USB flash drive may be pulled out again immediately, imagine pulling it out again within a second or two after the insertion, so we don't have to wait for the next time to detect it.

 

For the first row, determine delay_use> 0, and then for the second row, wait_event_interruptible_timeout (). Its first parameter is us-> delay_wait.

 

At the beginning of the storage_probe () function, delay_wait is initialized during the initialization of the us. Line 3: init_waitqueue_head (& us-> delay_wait). When structus_data is defined, a member is delay_wait, that is, wait_queue_head_t delay_wait. What does this mean?

 

In fact, wait_event_interruptible_timeout () is a macro, which represents a waiting mechanism in Linux, waiting for an event. In the function prototype, 1st parameters are a waiting queue header, that is, the variable defined by wait_queue_head_t. In the 2.6 kernel, use the init_waitqueue_head () function to initialize the waiting queue. Then, the 3rd parameters are set to time-out. For example, if the value is set to 5 seconds, the function returns 0 if the value reaches 5 seconds, regardless of other conditions. The first parameter is a waiting condition, or a waiting event. If the condition is met, the function will return. If the condition is not met, the process will go to sleep, however, interruptible indicates that the signal can interrupt it.

 

Once sleep, there are three situations: one is that the wake_up or wake_up_interruptible function is executed by another process to wake it up, the other is that the signal is interrupted, and the third is the timeout, when the time is reached, it will naturally return.

 

In this case, first determine whether the flag of us_f1_x_disconnecting is set. If no setting is set, the system goes to sleep. Otherwise, it is unnecessary to waste the feelings of each other. After going to sleep, if the USB flash drive is not pulled out within five seconds, the function returns 0 once every five seconds. If the USB flash drive is pulled out five seconds ago, then we will talk about it later. The storage_disconnect () function will be executed, it will set the flag us_f1_x_disconnecting, And it will call wake_up (& us-> scsi_scan_wait) to wake up the sleep process here, tell it: "Don't wait, dude, you don't have that life!" In this way, the function will be returned in advance, without waiting for 5 seconds to return. In short, no matter the condition is not met, it will certainly return within five seconds, so let's continue to look down.

 

Row 3, try_to_freeze (), which is the content of power management.

 

Line 3: Check whether the device is disconnected again. If not, run the scsi_scan_host () function Scan, scan and then you will know the host or the device connected to the scsicard (although we only simulate the scsicard), and then cat/proc/scsi will be able to see your USB flash drive.

 

For devices with multiple Luns, call usb_stor_Bulk_max_lun () to obtain max_lun.

 

Then, Row 3 shows the complete_and_exit function, which is different from the complete function. In addition to awakening others, you have to end yourself (exit ). It is in kernel/exit. c:

 

1010 NORET_TYPE void complete_and_exit (structcompletion * comp, long code)

 

1011 {

 

1012 if (comp)

 

1013 complete (comp );

 

1014

 

1015 do_exit (code );

 

1016}

 

The most important function in this function is the do_exit () function. Needless to say, it is a function provided by the kernel and ends the process. That is to say, for the sprite process of the scan above, it will end and quit. It can be seen that it is a short-lived daemon. In short, for this genie process, its mission is to enable you to see your USB flash disk in cat/proc/scsi. Of course, then you can see your device in the/dev directory, such as/dev/sda.

 

Let's take a look at the parent process, that is, storage_probe (). After we use kernel_thread () to create usb_stor_scan_thread, storage_probe () will also come to an end if everything is normal. Row 3 and return 0. Finally, the old legend finally came to the old moment, and everything was over.