Common header file for FC definitions
RFC 1/1 Common header file for FC definitions
zfcp has a couple of definitions to describe the FC protocol. Grepping through the complete source tree shows that e.g. the lpfc module makes similar private definitions. It think that it would make sense to introduce a global header file for FC related definitions that each FC driver can use.
The attached patch contains some definitons that i found in zfcp and could be reused by other drivers.
What do others think? Would this be useful?
Christof
--- include/scsi/fc.h | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)
include/scsi/fc.h new file +47 -0
@@ -0,0 +1,47 @@ +/* +* Public definitions that are used by Fibre Channel (FC) +* device drivers. +*/ + +/* FC-PH/FC-GS well-known address identifiers for generic services */ +#define FC_DID_KEY_DISTRIBUTION_SERVICE 0xFFFFF7 +#define FC_DID_ALIAS_SERVICE 0xFFFFF8 +#define FC_DID_MANAGEMENT_SERVICE 0xFFFFFA +#define FC_DID_TIME_SERVICE 0xFFFFFB +#define FC_DID_DIRECTORY_SERVICE 0xFFFFFC + +#define FC_DID_MASK 0x00FFFFFF + +/* task attribute values in FCP-2 FCP_CMND IU */ +#define SIMPLE_Q 0 +#define HEAD_OF_Q 1 +#define ORDERED_Q 2 +#define ACA_Q 4 +#define UNTAGGED 5 + +/* task management flags in FCP-2 FCP_CMND IU */ +#define FCP_ABORT_TASK_SET 0x02 +#define FCP_CLEAR_TASK_SET 0x04 +#define FCP_LOGICAL_UNIT_RESET 0x10 +#define FCP_TARGET_RESET 0x20 +#define FCP_CLEAR_ACA 0x40 + +/* FC-LS */ +#define FC_LS_RLS 0x0f +#define FC_LS_ADISC 0x52 +#define FC_LS_RPS 0x56 +#define FC_LS_RSCN 0x61 +#define FC_LS_RNID 0x78 + +/* +* FC-GS-2 +*/ +#define FC_CT_REVISION 0x01 +#define FC_CT_DIRECTORY_SERVICE 0xFC +#define FC_CT_NAME_SERVER 0x02 +#define FC_CT_SYNCHRONOUS 0x00 +#define FC_CT_GID_PN 0x0121 +#define FC_CT_MAX_SIZE 0x1020 +#define FC_CT_ACCEPT 0x8002 +#define FC_CT_REJECT 0x8001 +
Quoted 10 lines · Christof Schmitt
zfcp has a couple of definitions to describe the FC protocol. Grepping through the complete source tree shows that e.g. the lpfc module makes similar private definitions. It think that it would make sense to introduce a global header file for FC related definitions that each FC driver can use.
The attached patch contains some definitons that i found in zfcp and could be reused by other drivers.
What do others think? Would this be useful?
This is a very good idea. It might make more sense to have the more or less complete defintions for the fc protocol in the header. Robert & folks have been working on a software fc stack part as the fcoe header so they might have one to contribute.
Quoted 10 lines · Christoph Hellwig
Quoted 9 lines · Christof Schmitt
zfcp has a couple of definitions to describe the FC protocol. Grepping through the complete source tree shows that e.g. the lpfc module makes similar private definitions. It think that it would make sense to introduce a global header file for FC related definitions that each FC driver can use.
The attached patch contains some definitons that i found in zfcp and could be reused by other drivers.
Quoted 6 lines
Quoted 1 line
What do others think? Would this be useful?
This is a very good idea. It might make more sense to have the more or less complete defintions for the fc protocol in the header. Robert & folks have been working on a software fc stack part as the fcoe header so they might have one to contribute.
I Agree - A common header for standard FC definitions would be a good thing.
That said, we have to be a little lenient on when drivers convert over to the standard headers as there's likely code change required.
-- james s
Quoted 18 lines · James Smart
Quoted 10 lines · Christoph Hellwig
Quoted 9 lines · Christof Schmitt
zfcp has a couple of definitions to describe the FC protocol. Grepping through the complete source tree shows that e.g. the lpfc module makes similar private definitions. It think that it would make sense to introduce a global header file for FC related definitions that each FC driver can use.
The attached patch contains some definitons that i found in zfcp and could be reused by other drivers.
Quoted 6 lines
Quoted 1 line
What do others think? Would this be useful?
This is a very good idea. It might make more sense to have the more or less complete defintions for the fc protocol in the header. Robert & folks have been working on a software fc stack part as the fcoe header so they might have one to contribute.
Quoted 4 lines
I Agree - A common header for standard FC definitions would be a good thing.
That said, we have to be a little lenient on when drivers convert over to the standard headers as there's likely code change required.
For zfcp, i would like to move the FC specific definitions out of the zfcp_def.h header file. My idea would be to introduce a simple header file like proposed and to adapt zfcp to use these. I don't intend to write header files for the full FC protocol, since zfcp only uses a small part. When other drivers use more definitions, then the definitions can be added to the existing file.
When other drivers want to use the global definitions, they can include the global file, but they don't have to.
Would others also be interested in having structs in the global header file for FC commands like this?
struct zfcp_ls_adisc {
u8 code;
u8 field[3];
u32 hard_nport_id;
u64 wwpn;
u64 wwnn;
u32 nport_id;
} __attribute__ ((packed));This could be renamed to fc_ls_adisc and also be part of the global header file. But probably it makes more sense to start simple now and think about the common structs later.
Thanks for the comments.
Christof
Quoted 10 lines · Christof Schmitt
zfcp has a couple of definitions to describe the FC protocol. Grepping through the complete source tree shows that e.g. the lpfc module makes similar private definitions. It think that it would make sense to introduce a global header file for FC related definitions that each FC driver can use.
The attached patch contains some definitons that i found in zfcp and could be reused by other drivers.
What do others think? Would this be useful?
This is good idea. It could be widely used for FC drivers across the vendors as their features get added. Especially for Link Services including FC-CT protocol.
Thank you,
Seokmann