I am USB in Linux, I am a USB flash drive (17). Will it be far away in spring? (3)

Get what we need from the two tables, and then the following code is expanded around the two pointers. (Unusual_dev and id) continue to read get_device_info (). Row 3: record unusual_dev in us. There is also such a member in us. After this is recorded...

 

Get what we need from the two tables, and then the following code is expanded around the two pointers. (Unusual_dev and id) continue to read get_device_info ().

 

Row 3: record unusual_dev in us. There is also such a member in us. In this way, it will be easy to use after recording. because us runs through the whole story, it is very convenient to access its members and can be accessed at any time, however, the us_unusual_dev_list and storage_usb_ids tables will not be reused this time. Because we have obtained what we want, we don't need to harass these two arrays any more.

 

From rows 498 to 504, assign values to the other three members of us, subclass, protocol, and flags. For example, our USB flash drive is a mainstream device and can be found in the us_unusual_dev_list list. its subclass is US_ SC _SCSI, and protocol is Bulk-only, which is represented by the macro US_PR_BULK.

 

US_ SC _DEVICE and US_PR_DEVICE have already seen Samsung's digital cameras before. it indicates that subclass and protocol must be read from the device descriptor. This looks funny because Samsung can clearly write subclass and protocol in UNUSUAL_DEV. why should we read the device descriptor? However, we can imagine that the advantage of this is that defining an UNUSUAL_DEV can represent several devices, that is, it can share such a macro with several devices of different subclass, or several devices with different protocols share the same macro. Note that, for a USB flash drive, it does not have flags to be set, but many devices in unusual_devs.h have various flags, later, we will see in the code that we have to judge whether a flag is set from time to time. generally, if it is set, we need to execute more code to meet certain requirements.

 

Lines 523 to lines 551. this is a pure debugging code that makes no sense for us to understand USB. This code checks unusual_devs.h to see if this file defines a meaningless sentence. What is meaningless? As we saw just now, if this device has US_ SC _DEVICE, its subclass will be read from the descriptor. if it is not, let subclass = unusual_dev-> useProtocol, however, if the latter is the same as the one read in the descriptor, this device does not need to define its useProtocol in unusual_devs.h, because it can also be read from the descriptor. It is better to set US_ SC _DEVICE as the public. For example, let's look at the following line representing the code of a Sony Memory Stick product:

 

629 UNUSUAL_DEV (0x054c, 0x0069, 0x0000, 0x9999,

 

630 "Sony ",

 

631 "Memorystick MSC-U03 ",

 

632 US_ SC _UFI, US_PR_CB, NULL,

 

633 US_FL_SINGLE_LUN ),

 

We can see that US_ SC _UFI is written in the useProtocol column, which indicates that it claimed to belong to UFI SubClass, but this is also true if we read it from its descriptor, so there is no need to indicate here. it is better to write US_ SC _DEVICE directly here. Of course, in general, this code is silly. To write code, you want to better manage unusual_devs.h and do not want it to be constantly added. it always wants to delete some rows from this file, and even if it cannot delete a row, I also hope that every line will look neat, so that this file will look more compact and exquisite. Instead of increasing constantly.

 

So far, the get_device_info function has ended its mission. In the USB Storage, it will no longer appear. But I would like to say that for the entire module of USB Storage, the leading role is not important, and every function is a touch of color on the canvas. Just like every one of us is not a supporting role in others' lives, but is it always the main character in our own life?