SCSI Driver Model

Position of the SCSI driver in the kernel

The core of the SCSI driver is the bus-layer driver, which is driven by a variety of SCSI devices and the SCSI host driver under the bus-layer driver. The position in the kernel is shown in:

<! -- [If! VML] --> <! -- [Endif] -->

　　2.3 Linux SCSI driver framework

In Linux, the SCSI driver has three layers: top level, middle level, and lower level. The top level is the driver of a specific SCSI device. For example, the driver of a commonly used disk device is on this layer (the implementation in Linux is SD. c) The SCSI disk driver is represented as a block device in the upward direction. Therefore, it has the interface and all attributes of the block device and represents the SCSI device in the downward direction, because the SCSI disk performs Data Communication Based on the SCSI bus. The top level driver is related to a specific SCSI device. Therefore, this type of driver is usually provided by the device developer. However, if the SCSI device is a standard device, the driver can be used universally. Middle
Level is actually a SCSI bus-layer driver, which performs device enumeration, data transmission, and error handling according to the SCSI protocol. The driver at the level layer of the middle is related to SCSI specification. It is only required to be implemented once on a type of operating system platform. Therefore, this type of driver is usually provided by operating system developers. The lower level is the SCSI controller driver. The driver is related to the specific hardware Adapter. It needs to be connected to the SCSI middle level layer. Therefore, the hardware vendor that provides the adapter often completes driver development, only the hardware vendor can clearly define the register file. Of course, virtual SCSI can be implemented at the lower level layer.
Host, so the driver of this layer does not necessarily operate on the hardware.

In Linux, the SCSI three-layer driver model is shown in:

The three-layer driver model is fully divided into functions and well-defined interfaces, so that the products provided by different developers can be seamlessly integrated. This article will focus on the implementation mechanism and functional interfaces of the SCSI middle level driver provided by the operating system.

　　3. scsi middle level layer important data structure

3.1 SCSI device Abstraction

The SCSI middle level defines the data structure of the SCSI device, which is used to describe a SCSI Functional Unit. It is addressable in the SCSI host through channel, ID, Lun.

There can be multiple channels in the SCSI host. Each channel is a complete SCSI bus. On the SCSI bus, multiple SCSI nodes can be connected. Each node is numbered by ID, the number size is related to the specific SCSI specification, and to factors such as the driver capability of the bus layer. Each node can be divided into multiple Luns based on functions, and each Lun is what we usually call a SCSI device. This logic can be described using the following bus topology:

The above description shows that scsi_device is an abstraction of Lun. The important fields in scsi_device are described as follows:

During the SCSI bus probe process, SCSI middle level abstracts each Lun into a SCSI device and implements the core function scsi_probe_and_add_lun ().

　　3.2 SCSI host Abstraction

SCSI host has a clear syntax and describes a SCSI bus controller. In many practical systems, SCSI host is a PCI bus-based HbA or a SCSI controller chip. Each SCSI host can have multiple channels, and a channel actually extends a SCSI bus. Each channel can connect multiple SCSI nodes. The number of connections depends on the SCSI bus carrying capacity. The important fields of SCSI host are described as follows:

　　3.3 SCSI target Abstraction

SCSI target abstracts SCSI nodes on the SCSI bus. Each SCSI target may have multiple Luns, that is, multiple SCSI devie. The important domains in the SCSI target data structure are defined as follows:

　　3.4 low-level interface method -- scsi_host_template

SCSI middle level uses the scsi_host_template interface to call the method of SCSI host. When the SCSI host driver registers a Host Object with middle level, it must register the scsi_host_template method. This method is registered in the SCSI Host object.

Important Fields in the scsi_host_template data structure are described as follows:

Click to view the source Image

A typical scsi_host_template method is defined as follows:

　　4. Key Function Analysis

4.1 scsi_scan_host Function

The SCSI middle level layer provides the SCSI host scanning function. During device enumeration, the SCSI host can call this function to scan the SCSI bus adapter, of course, the host driver can also call more underlying functions to scan the SCSI bus. The implementation process of the scsi_scsn_host function is as follows:

　　4.2 scsi_request_fn Function

The scsi_request_fn function is the SCSI device Request queue processing function, which is usually registered to request_queue-> request_fn. The bio requested by the block device will eventually merge to the Request queue, and then use the unplug_fn function to call request_queue-> request_fn to call the scsi_reuqest_fn function.

The scsi_request_fn function implements the processing of request queues. First, extract a request from the request queue, convert the request to a SCSI command through the Q-> prep_rq_fn function, and initialize the SCSI command, finally, the SCSI command is distributed to the underlying SCSI host driver through the scsi_dispatch_cmd function.

During the implementation of the scsi_request_fn function, the corresponding SCSI commands need to be constructed through requests sent from Block devices. The generation of SCSI commands is related to the specific device driver, it needs to call the SCSI command initialization function * _ init_command provided by the device driver to complete the command initialization process. Assume that the request is sent to the SCSI disk device. The function call relationships between layers are shown in:

From the previous analysis, we can see that the request queue is the link between top level and middle level. Upper-layer requests are maintained in the Request queue, and the processing function is provided by the upper and lower layers. During the processing of the request queue, common block device requests are converted to standard SCSI commands, and then the requests are submitted to the SCSI host through the interface between the middle level and low level.

　　4.3 scsi_dispatch_cmd Function

The scsi_dispatch_cmd function submits a SCSI command to the underlying SCSI host driver. During the command dispatch process, the middle level checks whether the SCSI host is in the busy State and whether there is space to store the new SCSI command. If all the conditions are met, the queuecommand function between the upper and lower layers is called to forward the request.

The implementation of the queuecomand function is completed by the SCSI host driver. Generally, the implementation of this function is very simple. You only need to mount the passed SCSI command to the host's SCSI command queue. Because the queuecommand function runs in the context where the spinlock is held, it is not recommended to perform too many complex operations. Otherwise, it is easy to cause sleep of the program and the program running is unstable.

　　5. scsi device scan process description

When the computer system is started, the operating system scans the default PCI root node, which triggers the PCI device scan process and begins to build the PCI Device Tree.

The SCSI host, as a PCI device, will be scanned by the driver layer of the PCI bus (the PCI device uses the read configuration information method). After scanning the SCSI host, the operating system starts to load the SCSI host driver. The SCSI host driver is the low level driver mentioned above. SCSI host driver initializes the SCSI controller, allocates hardware resources through PCI configuration space information, and registers for service interruption. Finally, scan the SCSI bus, which is extended by the SCSI controller.

SCSI bus scanning is completed through the services provided by SCSI middle level. The SCSI host driver can call the scan algorithm provided by SCSI middle level to scan SCSI bus devices. The scan process can be described as follows:

Click to view the source Image

The following important functions of the SCSI middle level layer are used during SCSI bus scanning:

1. scsi_scan_host: scans the SCSI host device.

2
Scsi_add_device: detects a specific device and adds it to the system.

3. scsi_probe_and_add_lun: detects a specific Lun and adds it to the system.

4. scsi_probe_lun: Use the inquiry command to test the Lun node.

5. scsi_add_lun: joins the Lun node and initializes the SCSI device.

Shows the function calls during SCSI bus scan:

　　6. scsi device read/write process

Here is a process for reading and writing data from a SCSI device. Using this example, you can easily find the Linux source code and clarify the complicated code structure. Assume that the read/write SCSI device is a SCSI disk device, and the data first enters the cache of the file system through the file system. The file system's pdflush daemon will refresh the cached data to the disk.
The header content constructs bio, and then calls the block device interface (submit_bio) to send the request to the block device layer. Bio is forwarded multiple times at the block device layer, and is finally sent to the Request queue of the block device by merge. Requests may stay in the Request queue for a period of time, and then call request_fn in the Soft Interrupt or user context to process the Request queue. In the SCSI middle level driver layer, block device requests are converted to SCSI
Command, and then submit the SCSI command to the SCSI host through the queuecommand function interface. Usually, the SCSI host initiates a DMA Operation to transmit data to a specific device. So far, the data has been transferred from the application to the SCSI device. Of course, the above process does not involve the callback process, and the actual callback will be completed in the interrupt context and Soft Interrupt context, the corresponding callback context is saved at each layer of the request. The functions involved in the entire data flow process are as follows:

　　7. Summary of SCSI middle level-layer driver design ideas

The SCSI middle level still has many implementation details not discussed, and many detailed issues will be given in the subsequent blog. Here we only provide the framework of the SCSI middle level, it is intended to have a programmatic effect on the SCSI bus layer. During the analysis of SCSI middle level, I have the following thoughts:

<! -- [If! Supportlists] --> 1. <! -- [Endif] --> the SCSI driver adopts a standardized hierarchical design concept, which is divided into three layers. After layering, the design division is clearer and logically clearer, the design work is also simpler.

<! -- [If! Supportlists] --> 2. <! -- [Endif] --> the SCSI driver has a fixed level of SCSI middle level, which can be called the SCSI common middle layer or the bus driver layer. Interfaces must be provided for both the upstream and downstream layers. Therefore, relevant interface functions must be registered during upper-layer driver development, and interface functions must also be registered when the lower-layer driver is working, only in this way can the intermediate layer be flexibly used for data transmission between the upper and lower layers.

SCSI middle level mainly implements SCSI bus scanning algorithms, SCSI command conversion algorithms, and SCSI error handling mechanisms. These are the core of SCSI.