On Wed, 13 Oct 2021 15:00:07 -0700 Bart Van Assche <bvanassche@xxxxxxx> wrote: > On 10/12/21 11:50 PM, Yanling Song wrote: > > On Tue, 12 Oct 2021 09:59:30 -0700 > > Bart Van Assche <bvanassche@xxxxxxx> wrote: > >> Why is it that SG_IO is not sufficient? This is something that > >> should have been explained in the patch description. > > > > There are two cases that there are no SG devices and SG_IO cannot > > work. 1. To access raid controller: > > a. Raid controller is a scsi host, not a scsi device, so there > > is no SG device associated with it. > > b. Even there is a scsi device for raid controller, SG_IO > > cannot work when something wrong with IO queue and only admin queue > > can work; > > 2. To access the physical disks behinds raid controller: > > raid controller only reports VDs to OS and only VDs have SG > > devices. OS has no idea about physical disks behinds raid > > controller and there is no SG devices associated with physical > > disks. > > Please take a look at the bsg_setup_queue() call in ufs_bsg_probe(). > That call associates a BSG queue with the UFS host. That queue > supports requests of type struct ufs_bsg_request. The Fibre Channel > transport driver does something similar. I believe that this is a > better solution than introducing entirely new ioctls. I wish there was a standard way to address the ioctrl issue. Unfortunately ioctrl is the only way to meet our requirements as listed in the above. As discussed in previous megaraid's patchsets: https://lore.kernel.org/linux-scsi/yq1inc2y019.fsf@xxxxxxxxxx/, that's why every raid controller has it's own ioctrl.
