On 2018-08-09 07:51 PM, Bart Van Assche wrote:
On Thu, 2018-08-09 at 23:32 +0000, Avri Altman wrote:
And as I said before, we think that maintaining the flexibility to have more-than-one
bsg device nodes, will be useful serving as a testing and validation environment.
That is a very vague statement. Please clarify.
"...
In addition to the basic SCSI core objects this transport class
introduces two additional (currently empty) class objects:
“ufs-host” and “ufs-port”. There is only one “ufs-host” in the
system, but can be more-than-one “ufs-ports”.
..."
Since both the ufs-host and ufs-port objects are empty, can both be left out?
But mustn't I declare those classes for the various components of the scsi transport to work?
Are you perhaps referring to the transport_class_register() calls in SCSI
transport drivers? From what I see in existing SCSI transport drivers the
transport_class_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.
If there is a one-to-one relationship between a UFS initiator, target and
logical unit then you could communicate with the driver using SCSI READ BUFFER
and WRITE BUFFER commands. Both have a vendor specific MODE value (0x1).
Also pick a non-default MODE SPECIFIC value (e.g. 110b) to lessen the chances
of clashing with a LU that is using the same technique.
Then you can read and write data to the ufs driver (initiator) as much as you
like via the ioctl(SG_IO) via its storage logical unit.
Another slightly more structured way would be to use the SCSI MANAGEMENT IN/OUT
commands with A MANAGEMENT PROTOCOL value of F0h to FFh (vendor specific).
Then if you need to configure the ufs driver to make the storage available
then driver could present a MANAGEMENT PROTOCOL "well-known logical unit"
(which is not so well known).
Doug Gilbert
