On Mon, 2010-11-01 at 21:56 +0900, FUJITA Tomonori wrote: > On Sat, 30 Oct 2010 16:05:43 -0700 > "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx> wrote: > > > One final question in that regard is in your ibmvscsis_queuecommand() > > code, only INQUIRY, REPORT_LUNS, and MODE_SENSE need to be handled > > specially for other non Linux VIO SRP Initiator guests on the other > > end.. > > INQUIRY and REPORT_LUNS need the special responses. Otherwise the > initiators can't see the logical units. > There also appears to be a bunch of magic bits set for MODE_SENSE as well and seems to indicate a hard requirement for legacy non linux guests, yes..? Also wrt to the internal REPORT_LUNs emuation, is it just the LUN encoding that is specific to ibmvscsis..? I am wondering if can just add a operation TCM fabric module TFO op for individual struct se_lun->unmapped_lun -> REPORT_LUN payload encode, and drop this internal emulation code. Thanks! --nab > > > I would like to break this out (if possible) into individual > > specialized CDB fields / bits if possible so these special cases so we > > can drop excess emulation code in ibmvscsis.c. This means we could > > (eventually) allow TCM/IBMVSCSIS to utilize the SPC-3+ emulation bits in > > INQUIRY for high level PR/ALUA emulation using SCSI_PROTOCOL_SRP for the > > EVPD=0x83 case. > > > > So then perhaps this is more a question for brking and the POWER IBM > > folks. Of the three CDBs in IBMVSCSIS (INQUIRY, REPORT_LUNS, and > > MODE_SENSE) that we are expecting to be done internally to fabric module > > code, are there any other specific bits you need set..? Are there in > > any bits/fields in the code below that can not *not* be set..? -- 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