On 15.09.2005 14:26 Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > I have a hard time understanding much of the driver and thus this > patch aswell, but it looks like you're adding the luns using scsi_add_device > instead of using the proper midlayer lun scan. Yes, you are right. The patch just adds kind of basic support for NPIV, e.g. handling error situations, giving information for problem determination. Next step is to allow lun scanning for ports operating in NPIV mode. I am working on that ... However for ports not operating in NPIV mode zfcp relies on scsi_add_device ;-( > > @@ -68,6 +68,8 @@ ZFCP_DEFINE_ADAPTER_ATTR(s_id, "0x%06x\n > > ZFCP_DEFINE_ADAPTER_ATTR(peer_wwnn, "0x%016llx\n", adapter->peer_wwnn); > > ZFCP_DEFINE_ADAPTER_ATTR(peer_wwpn, "0x%016llx\n", adapter->peer_wwpn); > > ZFCP_DEFINE_ADAPTER_ATTR(peer_d_id, "0x%06x\n", adapter->peer_d_id); > > +ZFCP_DEFINE_ADAPTER_ATTR(physical_wwpn, "0x%016llx\n", adapter->physical_wwpn); > this information belongs into the transport class, not the driver. > What's the peer information above? is that for point-to-point FC > connections? Hope it is acceptable to keep this attributes in zfcp sysfs subtree until I will send a patch to add physical port_name and physical port_id information to the transport class. Both attributes just make sense for ports operating in NPIV-mode and are helpful for problem determination. Yes, the peer information is for point-to-point connections. I plan to remove these attributes and to automatically configure the P2P-port in zfcp. But that is currently not the most important thing to do. > > ZFCP_DEFINE_ADAPTER_ATTR(fc_link_speed, "%d Gb/s\n", adapter->fc_link_speed); > dito this one belongs only in the transport class. I am just about to send a patch to move this and some other zfcp adapter attributes to the corresponding fc_host. Regards, Andreas - : 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
