On 11/5/21 6:02 AM, Yanling Song wrote:
We've studied BSG and in general it can work. The following is our draft design, please give your comments: 1. Applications from user space send commands to driver thru struct sg_io_v4, the private data(used by driver) is saved in sg_io_v4->request and the data length is saved in sg_io_v4->request_len. 2. SG_IO is used in bsg_ioctl(), the following has to be set because bsg_transport_check_proto() will check the fields: sg_io_v4->protocol = BSG_PROTOCOL_SCSI; sg_io_v4->subprotocol = BSG_SUB_PROTOCOL_SCSI_TRANSPORT; Does the above match the BSG design?
I think so. Sample user space code that submits to a BSG interface is available e.g. here: https://github.com/westerndigitalcorporation/ufs-utils/blob/dev/scsi_bsg_util.c
And one question: The number of queue and queue depth are hardcoded in bsg_setup_queue(). set->nr_hw_queues = 1; set->queue_depth = 128; Any reason to do it? how about it does not match the chip's capability? for example, the chip supports 8 hardware queues and each queue depth is 4096?
Will BSG commands be processed internally by the spraid driver or will these be sent to the hardware queues? If there is a need in the spraid driver for concurrent processing of BSG commands, feel free to make nr_hw_queues and/or queue_depth configurable. I recommend to do this by introducing a new structure (bsg_creation_params?) and by passing a pointer to that data structure to bsg_setup_queue(). Thanks, Bart.
