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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to