All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Thumshirn <jthumshirn@suse.de>
To: "Singhal, Maneesh" <Maneesh.Singhal@emc.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"JBottomley@odin.com" <JBottomley@odin.com>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>
Subject: Re: [PATCH] drivers/scsi/emcctd: drivers/scsi/emcctd: Client driver implementation for  EMC-Symmetrix GuestOS emulated Cut-Through Device
Date: Mon, 25 Jan 2016 10:16:37 +0100	[thread overview]
Message-ID: <20160125091637.GA29561@c203.arch.suse.de> (raw)
In-Reply-To: <82807C73E0BDBB498164AAE7B8F6A1481C618138@MX105CL01.corp.emc.com>

On Sat, Jan 23, 2016 at 05:33:31AM +0000, Singhal, Maneesh wrote:
> Hello Thumshirn.
> Thanks for taking out time to review the patch. I appreciate that. Please find my comments inlined.
> 

[...]

> > 
> > Wouldn't it be nice to have this in the Kconfig file? No user will ever
> > look
> > at the README file in the driver directory.
> 
> [MS>] Certainly, I will keep this README as it is (for someone who really reads this) and also add these details in Kconfig as well.
> > 

OK, I can live with this.

> > > diff --git a/drivers/scsi/emcctd/emc_ctd_interface.h
> > b/drivers/scsi/emcctd/emc_ctd_interface.h
> > > new file mode 100644
> > > index 0000000..58a0276
> > > --- /dev/null
> > > +++ b/drivers/scsi/emcctd/emc_ctd_interface.h
> > > @@ -0,0 +1,386 @@

[...]

> > > +
> > > +/* a CTD v010 scatter/gather list entry: */
> > > +struct emc_ctd_v010_sgl {
> > > +
> > > +	/* the physical address of the buffer: */
> > > +	emc_ctd_uint32_t emc_ctd_v010_sgl_paddr_0_31;
> > > +	emc_ctd_uint32_t emc_ctd_v010_sgl_paddr_32_63;
> > > +
> > > +	/* the size of the buffer: */
> > > +	emc_ctd_uint32_t emc_ctd_v010_sgl_size;
> > > +};
> > > +
> > > +/* a CTD v010 header: */
> > > +struct emc_ctd_v010_header {
> > > +
> > > +	/* the other address: */
> > > +	emc_ctd_uint16_t emc_ctd_v010_header_address;
> > > +
> > > +	/* the minor version: */
> > > +	emc_ctd_uint8_t emc_ctd_v010_header_minor;
> > > +
> > > +	/* the what: */
> > > +	emc_ctd_uint8_t emc_ctd_v010_header_what;
> > > +};
> > 
> > Well this is a matter of taste but you have (and not only in this struct,
> > just
> > an example)
> > 
> > emc_ctd_v010_header.emc_ctd_v010_header_address
> > 
> > all the emc_ctd_v010_header_ stuff is totally redundant and you
> > suffer from extremely
> > long lines in your dirver anyways. Just a hint.
> [MS>] Well, didn't actually get what you meant here, header_stuff is getting used in the code, and is extremely useful as well.
> Also, I tried reducing long lines ... I don't think the left overs could be reduced in a better way.


I'd suggest the following:

/* a CTD v010 header: */
struct emc_ctd_v010_header {

	/* the other address: */
	u16 header_address;

	/* the minor version: */
	u8 header_minor;

	/* the what: */
	u8 what;
};

and then use it like:

static void
ctd_handle_response(union emc_ctd_v010_message *io_message,
				struct ctd_pci_private *ctd_private)
{
	struct emc_ctd_v010_header *msg_header;

	msg_header = &io_message->emc_ctd_v010_message_header;

	switch (msg_header->what) {

	case EMC_CTD_V010_WHAT_DETECT:
		ctd_handle_detect((struct emc_ctd_v010_detect *)io_message,
						ctd_private);

All the "emc_ctd_v010_header_" is unneeded redundant information, that doesn't
really solve a purpose in my opinion.

> > 
> > > +
> > > +/* a CTD v010 name: */
> > > +struct emc_ctd_v010_name {
> > > +
> > > +	/* the name: */
> > > +	emc_ctd_uint8_t emc_ctd_v010_name_bytes[8];
> > > +};
> > > +
> > > +/* a CTD v010 detect message: */
> > > +struct emc_ctd_v010_detect {
> > > +
> > > +	/* the header: */
> > > +	struct emc_ctd_v010_header emc_ctd_v010_detect_header;
> > > +
> > > +	/* the flags: */
> > > +	emc_ctd_uint32_t emc_ctd_v010_detect_flags;
> > > +
> > > +	/* the name: */
> > > +	struct emc_ctd_v010_name emc_ctd_v010_detect_name;
> > > +
> > > +	/* the key: */
> > > +	emc_ctd_uint64_t emc_ctd_v010_detect_key;
> > > +};
> > > +

[...]

> > > +
> > > +/* nomenclature for versioning
> > > + * MAJOR:MINOR:SUBVERSION:PATCH
> > > + */
> > > +
> > > +#define EMCCTD_MODULE_VERSION "2.0.0.24"
> > > +
> > > +MODULE_LICENSE("GPL");
> > > +MODULE_AUTHOR("EMC");
> > > +MODULE_DESCRIPTION("EMC CTD V1 - Build 18-Jan-2016");
> > 
> > This is very misleading. If I was a user I'd think the kernel was build on
> > 18-Jan-2016. Anyways The version should be enough.
> [MS>] I actually wanted to understand when this driver was last touched, and hence this description was added.
> > 

If you insist.

> > > +MODULE_VERSION(EMCCTD_MODULE_VERSION);
> > > +

[...]

> > > +#define ctd_dprintk(__m_fmt, ...)		\
> > > +do {				\
> > > +	if (ctd_debug)		\
> > > +		pr_info("%s:%d:"__m_fmt, __func__, __LINE__,
> > ##__VA_ARGS__); \
> > > +} while (0)
> > 
> > Please use pr_debug() here.
> [MS>] Sure.
> > 
> > > +
> > > +#define ctd_dprintk_crit(__m_fmt, ...)		\
> > > +		pr_crit("%s:%d:"__m_fmt, __func__, __LINE__,
> > ##__VA_ARGS__)
> > 
> > File and line information is probably not of any interest for the users
> > and
> > serves a debugging purpose only.
> [MS>] That's precisely why it is there...

Then please use the kernel's dynamic debug facility.

Thanks,
	Johannes
-- 
Johannes Thumshirn                                          Storage
jthumshirn@suse.de                                +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

  reply	other threads:[~2016-01-25  9:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-19 11:58 [PATCH] drivers/scsi/emcctd: drivers/scsi/emcctd: Client driver implementation for EMC-Symmetrix GuestOS emulated Cut-Through Device Singhal, Maneesh
2016-01-19 11:58 ` Singhal, Maneesh
2016-01-19 13:50 ` Johannes Thumshirn
2016-01-19 13:50   ` Johannes Thumshirn
2016-01-23  5:33   ` Singhal, Maneesh
2016-01-23  5:33     ` Singhal, Maneesh
2016-01-25  9:16     ` Johannes Thumshirn [this message]
2016-01-19 15:37 ` kbuild test robot
2016-01-19 15:55 ` kbuild test robot
2016-01-19 15:55   ` kbuild test robot
2016-01-19 16:04 ` Johannes Thumshirn
2016-01-19 16:04   ` Johannes Thumshirn
2016-01-23  5:51   ` Singhal, Maneesh
2016-01-23  5:51     ` Singhal, Maneesh
2016-01-25  9:26     ` Johannes Thumshirn
2016-01-25  9:30       ` Singhal, Maneesh
2016-01-25  9:30         ` Singhal, Maneesh
2016-01-25 10:08         ` Johannes Thumshirn
2016-01-25 10:16           ` Singhal, Maneesh
2016-01-25 10:16             ` Singhal, Maneesh
2016-01-19 18:12 ` Greg KH
2016-01-19 18:12   ` Greg KH
2016-01-23  6:04   ` Singhal, Maneesh

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=20160125091637.GA29561@c203.arch.suse.de \
    --to=jthumshirn@suse.de \
    --cc=JBottomley@odin.com \
    --cc=Maneesh.Singhal@emc.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.