From: "Bryant G. Ly" <bryantly@linux.vnet.ibm.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: nab@linux-iscsi.org, joe@perches.com, mikecyr@linux.vnet.ibm.com,
James.Bottomley@HansenPartnership.com, tyreld@linux.vnet.ibm.com,
brking@linux.vnet.ibm.com, akpm@linux-foundation.org,
bart.vanassche@sandisk.com, gregkh@linuxfoundation.org,
seroyer@linux.vnet.ibm.com, linux-scsi@vger.kernel.org,
target-devel@vger.kernel.org, martin.petersen@oracle.com
Subject: Re: [PATCH v7] ibmvscsis: Initial commit of IBM VSCSI Tgt Driver
Date: Thu, 23 Jun 2016 11:17:09 -0500 [thread overview]
Message-ID: <7BD61114-FF3C-4DBA-9B18-A12588DD7B8F@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160623142213.GA30453@infradead.org>
On 6/23/16, 9:22 AM, "Christoph Hellwig" <target-devel-owner@vger.kernel.org on behalf of hch@infradead.org> wrote:
>> -config SCSI_SRP
>> - tristate "SCSI RDMA Protocol helper library"
>> - depends on SCSI && PCI
>> - select SCSI_TGT
>> - help
>> - If you wish to use SRP target drivers, say Y.
>> -
>> - To compile this driver as a module, choose M here: the
>> - module will be called libsrp.
>> -
>
>Please split that removal of libsrp into a separate patch before
>adding the new driver.
Why do you suggest splitting the path up for the libsrp stuff? The current upstream
does not contain libsrp. The only reason the patch shows that there is a removal of
libsrp is that James Bottomley suggested doing a revert of:
libsrp: removal - commit f6667938cfceefd8afe6355ceb6497dce4883ae9
to make it clear that I’m bringing back what had existed a year ago within the upstream.
>
>> new file mode 100644
>> index 0000000..887574d
>> --- /dev/null
>> +++ b/drivers/scsi/ibmvscsi_tgt/Makefile
>> @@ -0,0 +1,4 @@
>> +obj-$(CONFIG_SCSI_IBMVSCSIS) += ibmvscsis.o
>> +
>> +ibmvscsis-objs := libsrp.o ibmvscsi_tgt.o
>
>please use module-y for adding objects. Also what's the reason
>for splitting these files?
>
I will change to module-y. The reason is we are possibly going to write
another target fabric in the future with the IBMVFC driver so just incase
we want to leave it separated for now.
>> +/*******************************************************************************
>> + * IBM Virtual SCSI Target Driver
>> + * Copyright (C) 2003-2005 Dave Boutcher (boutcher@us.ibm.com) IBM Corp.
>> + * Santiago Leon (santil@us.ibm.com) IBM Corp.
>> + * Linda Xie (lxie@us.ibm.com) IBM Corp.
>> + *
>> + * Copyright (C) 2005-2011 FUJITA Tomonori <tomof@acm.org>
>> + * Copyright (C) 2010 Nicholas A. Bellinger <nab@kernel.org>
>> + * Copyright (C) 2016 Bryant G. Ly <bryantly@linux.vnet.ibm.com> IBM Corp.
>> + *
>> + * Authors: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
>> + * Authors: Michael Cyr <mikecyr@linux.vnet.ibm.com>
>
>What's the reational for the copyright vs Authors lines?
No reason, ill remove the copyright.
>
>> +#include "ibmvscsi_tgt.h"
>> +
>> +#ifndef H_GET_PARTNER_INFO
>> +#define H_GET_PARTNER_INFO 0x0000000000000008LL
>> +#endif
>
>Should this be in a header with the other hcalls?
Yes, Moved.
>
>> +static const char ibmvscsis_driver_name[] = "ibmvscsis";
>
>I think you can just assign the name directly in the driver ops
>structure.
Fixed.
>
>> +static const char ibmvscsis_workq_name[] = "ibmvscsis";
>
>This one seems unused.
Removed
>
>> + vscsi->flags &= (~PROCESSING_MAD);
>
>No need for the braces here. (ditto for many other places later on)
>
>> +static long ibmvscsis_parse_command(struct scsi_info *vscsi,
>> + struct viosrp_crq *crq);
>
>Can you avoid forward declarations where easily possible, and if not
>keep them all at the beginning of the file?
Will do.
<SNIP>
>> +static int ibmvscsis_alloc_cmds(struct scsi_info *vscsi, int num)
>> +{
>> + struct ibmvscsis_cmd *cmd;
>> + int i;
>> +
>> + INIT_LIST_HEAD(&vscsi->free_cmd);
>> + vscsi->cmd_pool = kcalloc(num, sizeof(struct ibmvscsis_cmd),
>> + GFP_KERNEL);
>> + if (!vscsi->cmd_pool)
>> + return -ENOMEM;
>> +
>> + for (i = 0, cmd = (struct ibmvscsis_cmd *)vscsi->cmd_pool; i < num;
>> + i++, cmd++) {
>> + cmd->adapter = vscsi;
>> + INIT_WORK(&cmd->work, ibmvscsis_scheduler);
>> + list_add_tail(&cmd->list, &vscsi->free_cmd);
>> + }
>> +
>> + return 0;
>> +}
>
>Why can't you use the existing infrastructure for cmd pools in the
>target core?
>
I wasn’t aware there was existing infrastructure.
<SNIP>
>> + rc = srp_transfer_data(cmd, &vio_iu(iue)->srp.cmd, ibmvscsis_rdma, 1,
>> + 1);
>> + if (rc) {
>> + pr_err("srp_transfer_data failed: %d\n", rc);
>> + sd = se_cmd->sense_buffer;
>> + se_cmd->scsi_sense_length = 18;
>> + memset(se_cmd->sense_buffer, 0, se_cmd->scsi_sense_length);
>> + /* Current error */
>> + sd[0] = 0x70;
>> + /* sense key = Medium Error */
>> + sd[2] = 3;
>> + /* additional length (length - 8) */
>> + sd[7] = 10;
>> + /* asc/ascq 0x801 = Logical Unit Communication time-out */
>> + sd[12] = 8;
>> + sd[13] = 1;
>
>The Fabrics driver shouldn't generate it's own sense codes. This
>would for example break for a lun using descriptor format sense data.
Changed to:
if (rc) {
pr_err("srp_transfer_data failed: %d\n", rc);
sd = se_cmd->sense_buffer;
se_cmd->scsi_sense_length = 18;
memset(se_cmd->sense_buffer, 0, se_cmd->scsi_sense_length);
/* Fixed/Current Error = 0
* Sense Key = Medium Error (0x03)
* Additonal Length = 0xa
* Logical Unit Communication Time-out asc/ascq = 0x801
*/
scsi_build_sense_buffer(0, se_cmd->sense_buffer, MEDIUM_ERROR,
0x08, 0x01);
}
>--
>To unsubscribe from this list: send the line "unsubscribe target-devel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-06-23 16:17 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-26 14:58 [PATCH v2] ibmvscsis: Initial commit of IBM VSCSI Tgt Driver Bryant G. Ly
2016-05-27 14:32 ` [PATCH v3] " Bryant G. Ly
2016-05-28 4:27 ` Nicholas A. Bellinger
2016-06-09 21:26 ` [PATCH v4] " Bryant G. Ly
2016-06-10 19:05 ` Bart Van Assche
2016-06-14 6:35 ` Nicholas A. Bellinger
2016-06-14 8:46 ` Bart Van Assche
2016-06-14 14:57 ` Christoph Hellwig
2016-06-15 23:41 ` [PATCH v5] " Bryant G. Ly
2016-06-15 23:50 ` Joe Perches
2016-06-15 23:46 ` [PATCH v4] " Bryant G. Ly
2016-06-15 23:44 ` Bryant G. Ly
2016-06-14 8:09 ` Bart Van Assche
2016-06-15 23:43 ` Bryant G. Ly
2016-05-28 9:19 ` [PATCH v2] " Christoph Hellwig
2016-06-16 21:20 ` [PATCH v6] " Bryant G. Ly
2016-06-16 22:20 ` Joe Perches
2016-06-20 14:33 ` [PATCH v7] " Bryant G. Ly
2016-06-23 14:22 ` Christoph Hellwig
2016-06-23 16:17 ` Bryant G. Ly [this message]
2016-06-23 20:19 ` Michael Cyr
2016-06-27 20:17 ` [PATCH v8] " Michael Cyr
2016-06-28 20:56 ` Bryant G. Ly
2016-06-29 5:49 ` Bart Van Assche
2016-06-29 14:42 ` Bryant G. Ly
2016-06-29 14:54 ` Bart Van Assche
2016-06-29 15:22 ` Bryant G. Ly
2016-06-28 22:05 ` [PATCH v9] " Michael Cyr
2016-07-20 20:15 ` Nicholas A. Bellinger
2016-07-20 20:26 ` Bryant G. Ly
2016-07-20 22:25 ` Nicholas A. Bellinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7BD61114-FF3C-4DBA-9B18-A12588DD7B8F@linux.vnet.ibm.com \
--to=bryantly@linux.vnet.ibm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=bart.vanassche@sandisk.com \
--cc=brking@linux.vnet.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=joe@perches.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mikecyr@linux.vnet.ibm.com \
--cc=nab@linux-iscsi.org \
--cc=seroyer@linux.vnet.ibm.com \
--cc=target-devel@vger.kernel.org \
--cc=tyreld@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).