public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Christof Schmitt <christof.schmitt@de.ibm.com>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: Matthew Wilcox <matthew@wil.cx>, linux-scsi@vger.kernel.org
Subject: Re: [RFC] Move FC definitions from zfcp to global header
Date: Mon, 16 Jun 2008 13:14:10 +0200	[thread overview]
Message-ID: <20080616111409.GC7228@schmichrtp.de.ibm.com> (raw)
In-Reply-To: <485153CF.3010207@panasas.com>

On Thu, Jun 12, 2008 at 07:50:23PM +0300, Boaz Harrosh wrote:
> Matthew Wilcox wrote:
> > On Thu, Jun 12, 2008 at 03:02:46PM +0200, Christof Schmitt wrote:
> >> This was suggested a while ago, now i finally put together a patch
> >> that moves the Fibre Channel protocol definitions from zfcp to a new
> >> global header file. With the global header, the definitions can be
> >> shared across all FC drives.
> > 
> > I think this is a great step forward, thank you for doing it.
> > 
> >> +struct ct_hdr {
> >> +	u8 revision;
> >> +	u8 in_id[3];
> >> +	u8 gs_type;
> >> +	u8 gs_subtype;
> >> +	u8 options;
> >> +	u8 reserved0;
> >> +	u16 cmd_rsp_code;
> >> +	u16 max_res_size;
> >> +	u8 reserved1;
> >> +	u8 reason_code;
> >> +	u8 reason_code_expl;
> >> +	u8 vendor_unique;
> >> +} __attribute__ ((packed));
> > 
> > I question the need for packed.  Looking at <scsi/scsi.h>, none of the
> > structures there are packed.  Everything is naturally aligned and
> > explicitly padded ('reserved1', etc).  Also, those structs use __be16
> > instead of u16 to allow sparse to check the correct endian conversion
> > functions are used.
> > 
> 
> It's best to use the "__packed" macro which might be defined differently 
> for some tool-chains.
> 
> And it is best to *do* keep the __packed. At above example the biggest type
> is be16 so for >=32 bit arches it's packed the same, by all gcc versions. But
> if you start having bigger-then-natural types in a structure then different
> size arches will pack things differently. I have been bitten by this, even 
> though I kept everything well defined.
> 
> Also I like the __packed as a warning to fellow programmers that this is
> something on-the-wired defined.
> 
> And yes please use __be16 this is SCSI.

To use the above example, i this would be changed to:

struct ct_hdr {
	u8 revision;
	u8 in_id[3];
	u8 gs_type;
	u8 gs_subtype;
	u8 options;
	u8 reserved0;
	__be16 cmd_rsp_code;
	__be16 max_res_size;
	u8 reserved1;
	u8 reason_code;
	u8 reason_code_expl;
	u8 vendor_unique;
} __packed;

> > (same comment applies to other structs in the file)
> > 
> >> +struct fcp_cmnd_iu {
> >> +	u64 fcp_lun;
> > 
> > Should be a struct scsi_lun?

It is used in the same way, i will change it to struct scsi_lun.

> > This isn't right; the endianness has you confused.
> > 
> > +#elif defined(__LITTLE_ENDIAN_BITFIELD)
> > +	u8  task_attribute:3;
> > +	u8  reserved0:5;
> > +	u8  task_management_flags;
> > +	u8  wddata:1;
> > +	u8  rddata:1;
> > +	u8  add_fcp_cdb_length:6;
> > +#endif
> > 
> 
> Yes, that GCC bug on some ARCHES, rrrr. 
> Matthew is right the T10 standard always define the exact 
> byte-order which does not change. best just define:
> 
> 	u8  task_attribute;
> 	u8  task_management_flags;
> 	u8  wd_rd_add_fcp_cdb_length;
> 
> and use things like:
> enum {
> 	task_attribute_mask = 0xc0,
> 	task_attribute_shift = 5,
> 	wd_flag = 0x80,
> 	rd_flag = 0x40,
> 	add_fcp_cdb_length_mask = 0x3F

This would be correct, i think:
	wd_flag = 0x01,
	rd_flag = 0x02,
 	add_fcp_cdb_len_mask = 0xFC,

#define add_fcp_cdb_len_shift 2

> };
> 
> >> +	u8  fcp_cdb[FCP_CDB_LENGTH];
> >> +} __attribute__((packed));
> > 
> > I also wonder if we shouldn't define the fields that are in FCP-3.
> > 
> > I also wonder whether we should define bitfields or whether we should
> > let drivers mask and shift themselves.  That's jejb's call, IMO.
> > 

As i wrote before, i am currently focussing on the definitions used
for zfcp. If others require the FCP-3 fields, they can add them.

For the simple fields, the drivers can set them directly, e.g.
fcp_cmnd_iu.wd_rd_add_fcp_cdb_length |= rd_flag;

For things like the cdb_len, i would like to have a helper like
static inline set_add_fcp_cdb_len(struct fcp_cmnd_iu *fcp_cmnd_iu, u8 len)
{
	fcp_cmnd_iu->wd_rd_add_fcp_cdb_length |= (len << add_fcp_cdb_len_shift);
}

I will wait with the patch rework until we have completed some pending
zfcp cleanup patches, since changing the structs will conflict with
the other patches.

> My $0.017
> Boaz

Thanks for the feedback.

Christof

      reply	other threads:[~2008-06-16 11:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-12 13:02 [RFC] Move FC definitions from zfcp to global header Christof Schmitt
2008-06-12 15:19 ` Love, Robert W
2008-06-16 10:18   ` Christof Schmitt
2008-06-12 15:26 ` Matthew Wilcox
2008-06-12 16:50   ` Boaz Harrosh
2008-06-16 11:14     ` Christof Schmitt [this message]

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=20080616111409.GC7228@schmichrtp.de.ibm.com \
    --to=christof.schmitt@de.ibm.com \
    --cc=bharrosh@panasas.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=matthew@wil.cx \
    /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