Reputation: 61
How does in linux the scsi generic (sg) driver choose low-level driver(sd or sr) to use. I've found that the sg driver gets type of device from inquiry command.
sdev->type = (inq_result[0] & 0x1f);
After that "scsi_sysfs_add_sdev" function is called. And I doesn't see any using of field "->type" in this function.
Upvotes: 1
Views: 513
Reputation: 21
Sg doesn't go through those drivers.
Sg, Sd, Sr, and st are all "upper layer" scsi drivers. They talk to the scsi mid layer which in turn talks to the lower level driver (such as libata). I believe that means the routing descions are made by the mid layer drivers but I could be wrong and would like to be corrected if so.
For further information on the scsi mid layer, please see
https://docs.kernel.org/driver-api/scsi.html
Design of the Linux SCSI subsystem
The SCSI subsystem uses a three layer design, with upper, mid, and low layers. Every operation involving the SCSI subsystem (such as reading a sector from a disk) uses one driver at each of the 3 levels: one upper layer driver, one lower layer driver, and the SCSI midlayer.
The SCSI upper layer provides the interface between userspace and the kernel, in the form of block and char device nodes for I/O and ioctl(). The SCSI lower layer contains drivers for specific hardware devices.
In between is the SCSI mid-layer, analogous to a network routing layer such as the IPv4 stack. The SCSI mid-layer routes a packet based data protocol between the upper layer’s /dev nodes and the corresponding devices in the lower layer. It manages command queues, provides error handling and power management functions, and responds to ioctl() requests.
For more information on the design of SG, the author has an extremely in depth page.
https://sg.danny.cz/sg/sg_v40.html#__RefHeading___Toc1546_4294551682
4 Architecture of the sg driver
The Linux SCSI subsystem is made up of three parts: several upper level drivers (ULDs), one mid level, and multiple low level drivers (LLDs). The upper level drivers are divided up by the type of SCSI device: for disks the ULD is sd, for tape (drives) the ULD is st, for DVD/CDROMs the ULD is sr, for enclosures the ULD is ses. In most contexts the sg driver is considered a ULD, however in one context: when a LLD or user sets the no_uld_attach flag (see include/scsi/scsi_device.h), then that device is attached (i.e. receives an sg device node of the form /dev/sg (where is an integer starting at 0)) to the sg driver but to no other ULD. The SCSI devices attached to the sg driver may be thought of as the union of the devices from all the other ULDs plus any devices that don't have a type specific ULD supported such as a PROCESSOR DEVICE type used for managing enclosures using the SAFTE protocol. The mid-level maintains interfaces for both ULDs and LLDs and provides services such as device discovery, device teardown (e.g. at shutdown or suspend) and error processing. LLDs typically manage SCSI hardware (often call Host Bus Adapters (HBAs)) or bridge to another protocol stack (e.g. USB attached SCSI (UAS, also known as UASP in USB standards)).
Upvotes: 1