From: Matthew Wilcox <matthew@wil.cx>
To: Christof Schmitt <christof.schmitt@de.ibm.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [RFC] Move FC definitions from zfcp to global header
Date: Thu, 12 Jun 2008 09:26:24 -0600 [thread overview]
Message-ID: <20080612152624.GY30405@parisc-linux.org> (raw)
In-Reply-To: <20080612130245.GA13761@schmichrtp.de.ibm.com>
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.
(same comment applies to other structs in the file)
> +struct fcp_cmnd_iu {
> + u64 fcp_lun;
Should be a struct scsi_lun?
> + u8 crn;
> +#if defined(__BIG_ENDIAN_BITFIELD)
> + u8 reserved0:5;
> + u8 task_attribute:3;
> + u8 task_management_flags;
> + u8 add_fcp_cdb_length:6;
> + u8 rddata:1;
> + u8 wddata:1;
> +#elif defined(__LITTLE_ENDIAN_BITFIELD)
> + u8 wddata:1;
> + u8 rddata:1;
> + u8 add_fcp_cdb_length:6;
> + u8 task_management_flags;
> + u8 task_attribute:3;
> + u8 reserved0:5;
> +#endif
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
> + 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.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
next prev parent reply other threads:[~2008-06-12 15:26 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 [this message]
2008-06-12 16:50 ` Boaz Harrosh
2008-06-16 11:14 ` Christof Schmitt
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=20080612152624.GY30405@parisc-linux.org \
--to=matthew@wil.cx \
--cc=christof.schmitt@de.ibm.com \
--cc=linux-scsi@vger.kernel.org \
/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