Earlier, commit
1832a5862f2e1b4e5835611ee14bc30a8ed3cad5
"[SCSI] change port speed definitions for scsi_transport_fc"
changed the semantics of FC_PORTSPEED defines to match the Report Port
Speed Capabilities (RPSC) ELS of FC-GS/FS-LS instead of FC-HBA/SM-HBA.
It also mentions the problem that FC-HBA/SM-HBA and FC-GS/FC-LS contain
somewhat contradicting bit definitions for port speed.
Lately, commit
a9277e7783651d4e0a849f7988340b1c1cf748a4
"[SCSI] scsi_transport_fc: Getting FC Port Speed in sync with FC-GS"
reverted this.
(See also http://marc.info/?l=linux-scsi&m=132892310322550&w=2.)
However, there does not seem to be an explicit explanation of this.
While the source code comment of struct fc_host_attrs says its fields
adhere to HBAAPI 2.0, the comment of the FC_PORTSPEED defines does not
explicitly do so and a (new) user of the latter might not see the
relation to the structure fields, esp. since there is no obvious
relation in terms of C types other than being type compatible to a
generic int.
The commit message also does not say so but mentions SM-HBA along with
FC-GS without stating that they contradict themselves and FS-GS even
within the same document since it defines both RPSC ELS and FDMI port
attributes.
1) Is this change of semantics deliberate?
The commit message of a9277e7 states that user space is not affected
since it only sees text strings in the corresponding sysfs attributes.
Actually, commit c3d2350a8420dbf9d48f5f8a0fb72117bfcbc1b0
"[SCSI] fc_transport: update potential link speeds"
deliberately decided against syncing the bit definitions because of a
potential binary-incompatibility.
Is there some use of the bit definition that is not as transparent as
the text string based sysfs interface of an fc_host? E.g. using
scsi_transport_fc.h in user space libraries or applications (if this is
even allowed to be exported to user space)? I could find an in-kernel
binary use in libfc/fc_lport.c which could alternatively do a conversion
between the old RPSC ELS format of fc_host_{supported_}speed{s}() (and
libfc/fc_lport.c which has probably the same format as fc_host) when
building the FDMI blob in scsi/fc_encode.h:fc_ct_ms_fill()?
2) Why did commit a9277e7 change the kernel internal bit definitions?
The zfcp LLDD has been copying the supported speeds value directly from
what is reported by the HBA since the latter adheres to the RPSC ELS
format for line speeds. Since commit a9277e7 this is broken now and we
see 10 Gbit instead of 4 Gbit in the supported_speeds sysfs attribute of
the fc_host. I don't mind converting zfcp to an explicit finite bit
conversion based on individually defined constants, esp. since all other
FC LLDDs (qla2xxx, bfa, lpfc, ibmvscsi, fnic, mptfc) seem to do so
already. The only slight drawback I can see is that the code needs to be
touched for new HBA generations supporting new port speeds.
3) Should we have port speed defines for both RPSC ELS (in
include/fc/fc_els.h?) and FDMI port attributes (in
include/scsi/scsi_transport_fc.h? unless the bit semantic change gets
reverted)?
This way I could reuse the former to convert to the latter within zfcp
and other users can reuse it with regard to RPSC ELS. I would send a
patch if we agree on this.
4) Either way, should the port speed defines indicate RPSC ELS vs. FDMI
more explicitly in their identifier names, in order to avoid future
confusion?
Regards,
Steffen
Linux on System z Development
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
