On 24/09/2014 6:22, Sagi Grimberg wrote:
Since SRP_LOGIN_REQ/RESP has some free bits why not declare it and
activate it when both sides *says* they support it? I'd be much calmer
knowing we're on the safe side on this...
Hello Sagi,
Since more than ten years the SRP protocol is an official ANSI standard.
Since multichannel support has been defined in that standard my
preference is to follow what has been documented in that standard with
regard to multichannel operation. Using one of the free bits in the SRP
login request and response would involve a protocol modification. Hence
the proposal to add a blacklist for non-conforming target implementations.
Plus, I would like to run it on my performance setups. can you point me
to the SCST repo? is multichannel supported in scst trunk?
I think multichannel support was already present in the SCST SRP target
driver before I started maintaining that driver. However, last April a
few patches were checked in to improve multichannel support in the SCST
SRP target driver. These patches have been included in the SCST 3.0
release. Download instructions for SCST (3.0 and trunk) can be found
e.g. here: http://scst.sourceforge.net/downloads.html.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
