On Thu, 2018-08-09 at 23:32 +-0000, Avri Altman wrote: +AD4- And as I said before, we think that maintaining the flexibility to have more-than-one +AD4- bsg device nodes, will be useful serving as a testing and validation environment. That is a very vague statement. Please clarify. +AD4- +AD4APg- +ACI-... +AD4- +AD4APg- In addition to the basic SCSI core objects this transport class +AD4- +AD4APg- introduces two additional (currently empty) class objects: +AD4- +AD4APg- +IBw-ufs-host+IB0- and +IBw-ufs-port+IB0-. There is only one +IBw-ufs-host+IB0- in the +AD4- +AD4APg- system, but can be more-than-one +IBw-ufs-ports+IB0-. +AD4- +AD4APg- +AD4- +AD4APg- ...+ACI- +AD4- +AD4- +AD4-Since both the ufs-host and ufs-port objects are empty, can both be left out? +AD4- But mustn't I declare those classes for the various components of the scsi transport to work? Are you perhaps referring to the transport+AF8-class+AF8-register() calls in SCSI transport drivers? From what I see in existing SCSI transport drivers the transport+AF8-class+AF8-register() function is used to register link, port, host, vport, rport and other objects. I don't think that a SCSI transport driver is required to register host and port objects. Maybe we should take a step back and discuss first why the new bsg queues are registered by a transport driver? Since in case of UFS as far as I can see there is no real need to introduce a transport driver other than for creating the bsg device nodes, have you considered to add the code for creating bsg device nodes to the UFS driver instead of in a UFS transport driver? I think transport drivers were introduced as a way to share code between multiple SCSI LLDs that use the same transport mechanism. In the case of UFS there is only one SCSI LLD. Hence I'm wondering whether we really need an UFS transport driver. Thanks, Bart.
