>-----Original Message----- >From: Stefan Richter [mailto:stefanr@xxxxxxxxxxxxxxxxx] >Sent: Friday, January 04, 2008 4:10 PM >To: Dev, Vasu >Cc: FUJITA Tomonori; Love, Robert W; tomof@xxxxxxx; Zou, Yi; Leech, >Christopher; linux-scsi@xxxxxxxxxxxxxxx >Subject: Re: Open-FCoE on linux-scsi > >Stefan Richter wrote: >> I.e. you have SCSI command set layer -- SCSI core -- SCSI transport >> layer -- interconnect layer. > >The interconnect layer could be split further: >SCSI command set layer -- SCSI core -- SCSI transport layer (FCP) -- >Fibre Channel core -- Fibre Channel card drivers, FCoE drivers. This is how I see the comparison. ('/' indicates 'or') You suggest Open-FCoE SCSI-ml SCSI-ml scsi_transport_fc.h scsi_tranport_fc.h scsi_transport_fc.c (FC core) / HBA openfc / HBA fcoe / HBA fcoe / HBA >From what I can see the layering is roughly the same with the main difference being that we should be using more of (and putting more into) scsi_transport_fc.h. Also we should make the FCP implementation (openfc) fit in a bit nicer as scsi_transport_fc.c. We're going to look into making better use of scsi_transport_fc.h as a first step. I'm a little confused though; in a prior mail it seemed that you were clubbing openfc and fcoe together, and at one point Fujita's stack showed a libfcoe and fcoe fitting directly under scsi_transport_fc. I think the layering is nicer at this point in the thread, where SCSI only knows that it's using FC and the SW implementation of FCP knows the transport. It's closer to my understanding of Open-iSCSI. Open-iSCSI Open-FCoE scsi_transport_iscsi.c scsi_transport_fc.c iscsi_tcp.c fcoe I'm curious how aware you think scsi_transport_fc.h should be of FCoE? > >But this would only really make sense if anybody would implement >additional FC-4 drivers besides FCP, e.g. RFC 2625, which would also sit >on top of Fibre Channel core. >-- >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