On 9/24/2014 4:38 PM, Sagi Grimberg wrote:
On 9/24/2014 4:13 PM, Bart Van Assche wrote:
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.
Just re-visited the r16a, srp_login request req_flags include MULTI
CHANNEL ACTION (Table 10) and srp login response rsp_flags include
MULTI-CHANNEL RESULT (Table 12).
Did you notice those? Didn't see any reference in the patch...
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.
So I'm not so sure we need to update SRP login sequence...
Wait, yes you did reference those...
OK, I'm on board now...
Sagi.
--
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
