Dev, Vasu wrote: [FUJITA Tomonori wrote:] >> Agreed. My FCoE initiator design would be something like: >> >> scsi-ml >> fcoe initiator driver >> libfcoe >> fc_transport_class (inclusing fcoe support) >> >> And FCoE HBA LLDs work like: >> >> scsi-ml >> FCoE HBA LLDs (some of them might use libfcoe) >> fc_transport_class (inclusing fcoe support) Wouldn't it make more sense to think of fc_transport_class as a FCP layer, sitting between scsi-ml and the various FC interconnect drivers (among them Openfc and maybe more FCoE drivers)? I.e. you have SCSI command set layer -- SCSI core -- SCSI transport layer -- interconnect layer.¹ I am not familiar with FCP/ FCoE/ FC-DA et al, but I guess the FCoE support in the FCP transport layer should then go to the extent of target discovery, login, lifetime management and representation of remote ports and so on as far as it pertains to FCP (the SCSI transport protocol, FC-4 layer) independently of the interconnect (FC-3...FC-0 layers).² [...] >> The FCoE LLD needs to exploit the exsting struct fc_rport and APIs. > > The openfc is software implementation of FC services such as FC login > and target discovery and it is already using/exploiting existing fc > transport class including fc_rport struct. You can see openfc using > fc_rport in openfc_queuecommand() and using fc transport API > fc_port_remote_add() for fc_rport. Hence, aren't there interconnect independent parts of target discovery and login which should be implemented in fc_transport_class? The interconnect dependent parts would then live in LLD methods to be provided in struct fc_function_template. I.e. not only make full use of the API of fc_transport_class, also think about changing the API _if_ necessary to become a more useful implementation of the interface below FC-4. ------- ¹) The transport classes are of course not layers in such a sense that they would completely hide SCSI core from interconnect drivers. They don't really have to; they nevertheless live at a higher level of abstraction than LLDs and a lower level of abstraction than SCSI core. (One obvious example that SCSI core is less hidden than it possibly could be can be seen by the struct fc_function_template methods having struct scsi_target * and struct Scsi_Host * arguments, instead of struct fc_xyz * arguments.) ²) I'm using the term interconnect from the SCSI perspective, not from the FC perspective. -- Stefan Richter -=====-==--- ---= --=-= http://arcgraph.de/sr/ - 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
