[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6E21E5352C11B742B20C142EB499E0481B6EFEF0@TK5EX14MBXC126.redmond.corp.microsoft.com>
Date: Thu, 12 Jan 2012 17:55:45 +0000
From: KY Srinivasan <kys@...rosoft.com>
To: Christoph Hellwig <hch@...radead.org>
CC: "gregkh@...e.de" <gregkh@...e.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
"virtualization@...ts.osdl.org" <virtualization@...ts.osdl.org>,
"ohering@...e.com" <ohering@...e.com>,
"James.Bottomley@...senPartnership.com"
<James.Bottomley@...senPartnership.com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>
Subject: RE: [PATCH 1/1][RESEND] Staging: hv: storvsc: Move the storage
driver out of the staging area
Christoph,
Let me begin by first thanking you for your detailed review. I have addressed all the issues you have
identified - the code looks much better now; thank you! I am currently testing this code and I will post
the patches soon - individual patches against the current code in the staging tree as well as a patch to
move the driver out of staging (as I have done in the past). Please find my responses to your comments
in-line.
Regards,
K. Y
> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@...radead.org]
> Sent: Wednesday, January 11, 2012 5:37 AM
> To: KY Srinivasan
> Cc: gregkh@...e.de; linux-kernel@...r.kernel.org;
> devel@...uxdriverproject.org; virtualization@...ts.osdl.org; ohering@...e.com;
> James.Bottomley@...senPartnership.com; hch@...radead.org; linux-
> scsi@...r.kernel.org
> Subject: Re: [PATCH 1/1][RESEND] Staging: hv: storvsc: Move the storage driver
> out of the staging area
>
>
> I'd also really recommend splitting the actual protocol defintion in
> a header separate from the driver implementation to make it clear what
> is part of the protocol and what's internal to the driver.
I have consolidated all of the protocol defines at the start of the file and
these are properly commented. The decision to not have a separate header file
was based on the comments I got from the community a while ago. Hopefully,
this consolidation will address all the concerns.
>
> > +static inline struct storvsc_device *get_out_stor_device(
> > + struct hv_device *device)
>
> > +static inline struct storvsc_device *get_in_stor_device(
> > + struct hv_device *device)
>
> I'm pretty sure you defended this odd reference counting scheme last
> time the discussion came up, but please write up a long comment in
> the code explaning it so that the question doesn't come up again
> all the time.
I don't have any reference counting anymore. I have added a comment
explaining the protocol for managing the life-cycle.
>
> > + request_size = sizeof(struct storvsc_cmd_request);
> > +
> > + cmd_request = mempool_alloc(memp->request_mempool,
> > + GFP_ATOMIC);
> > + if (!cmd_request)
> > + return SCSI_MLQUEUE_DEVICE_BUSY;
>
> The point of the mempool allocator is that it will never return NULL.
With GFP_ATOMIC flag, the allocation I think can fail. At least that is what
mempool_alloc() comment says.
>
> > + /* max # of devices per target */
> > + host->max_lun = STORVSC_MAX_LUNS_PER_TARGET;
> > + /* max # of targets per channel */
> > + host->max_id = STORVSC_MAX_TARGETS;
> > + /* max # of channels */
> > + host->max_channel = STORVSC_MAX_CHANNELS - 1;
> > + /* max cmd length */
> > + host->max_cmd_len = STORVSC_MAX_CMD_LEN;
>
> Any reason these aren't set directly in the host template?
This state is not in the scsi_host_template. What am I missing here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists