On Fri, 2016-06-10 at 12:05 -0700, Bart Van Assche wrote:
> On 06/09/2016 02:26 PM, Bryant G. Ly wrote:
> > drivers/scsi/Kconfig | 27 +-
> > drivers/scsi/Makefile | 2 +-
> > drivers/scsi/ibmvscsi/Makefile | 4 +
> > drivers/scsi/ibmvscsi/ibmvscsi_tgt.c | 4184
> > ++++++++++++++++++++++++++++++++++
> > drivers/scsi/ibmvscsi/ibmvscsi_tgt.h | 347 +++
> > drivers/scsi/ibmvscsi/libsrp.c | 427 ++++
> > drivers/scsi/ibmvscsi/libsrp.h | 123 +
> > drivers/scsi/libsrp.c | 447 ----
> > include/scsi/libsrp.h | 78 -
>
> Sorry that I hadn't noticed this before but since no code is shared
> between the IBM vSCSI initiator and target drivers please consider
> moving the ibmvscsi_tgt.[ch] and libsrp.[ch] source files into a new
> directory. This will keep initiator and target drivers are in separate
> directories. This is the approach used for other upstream protocol
> drivers for which no code is shared between initiator and target drivers
> (e.g. the iSER, SRP initiator and target drivers).
Yeah, if no code is shared, and will ever be shared, we might as well
merge libsrc.[c,h] directly into ibmvscsi_tgt.[c,h].
> > +/**
> > + * ibmvscsis_modify_std_inquiry() - Modify STD Inquiry
> > + *
> > + * This function modifies the inquiry data prior to sending to initiator
> > + * so that we can support current AIX. Internally we are going to
> > + * add new ODM entries to support the emulation from LIO. This function
> > + * is temporary until those changes are done.
> > + */
> > +static void ibmvscsis_modify_std_inquiry(struct se_cmd *se_cmd)
> > +{
> > + struct se_device *dev = se_cmd->se_dev;
> > + u32 cmd_len = se_cmd->data_length;
> > + u32 repl_len;
> > + unsigned char *buf = NULL;
> > +
> > + if (cmd_len <= 8)
> > + return;
> > +
> > + buf = transport_kmap_data_sg(se_cmd);
> > + if (buf) {
> > + repl_len = 8;
> > + if (cmd_len - 8 < repl_len)
> > + repl_len = cmd_len - 8;
> > + memcpy(&buf[8], "IBM ", repl_len);
> > +
> > + if (cmd_len > 16) {
> > + repl_len = 16;
> > + if (cmd_len - 16 < repl_len)
> > + repl_len = cmd_len - 16;
> > + if (dev->transport->get_device_type(dev) == TYPE_ROM)
> > + memcpy(&buf[16], "VOPTA ", repl_len);
> > + else
> > + memcpy(&buf[16], "3303 NVDISK", repl_len);
> > + }
> > + if (cmd_len > 32) {
> > + repl_len = 4;
> > + if (cmd_len - 32 < repl_len)
> > + repl_len = cmd_len - 32;
> > + memcpy(&buf[32], "0001", repl_len);
> > + }
> > + transport_kunmap_data_sg(se_cmd);
> > + }
> > +}
>
> Christoph Hellwig had asked you *not* to modify the INQUIRY response
> generated by the target core. Had you noticed that comment?
>
Yeah, so I wanted to avoid having to add a new target_core_fabric_ops
API caller just for this special case, but there might not be another
choice..
Previously, ibmvscsi-tgt was simply picking off INQUIRY and doing
completion, setting the special payload buffer contents without actually
submitting to target-core.
I'd probably still prefer the original method to avoid the extra
target_core_fabric_ops API caller that will never be used by anybody
else, unless there are issues with AIX ordered tasks wrt INQUIRY not
actually making it into target-core.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
