On 05.01.2006 15:08 James Smart <James.Smart@xxxxxxxxxx> wrote: > Drop the physical_port_id attribute. I'm assuming that each virtual > port shows up as a unique scsi_host, as the FC ports and SCSI views it > has is unique to it's FC address (N_Port_ID). As such, the > physical_port_id would be redundant with the port_id on the scsi_host > that corresponds to the physical port. Rather than determine the > relationship through scsi_host attributes, you would determine the > relationship via multiple scsi_host children under the pci adapter under > the device tree. Obviously, if you don't buy into the scsi_host per > port_id relationship, things change and we should talk further. This all sounds sensible and I agree. Problem is that on the mainframe I don't have access to the primary port. Virtualization is done in adapter microcode. I just have access to the virtual port. Hence the primary port does not show up as a scsi_host. I cannot directly send any commands via the primary port. I just can get some information about the primary port (i.e. WWPN/N_Port_ID). This information I like to display in sysfs for troubleshooting purposes. (E.g. To check whether the primary port shows up on the switch.) Seems that requirements for workstations and mainframes are contrary. > As for physical_port_name, minimally, this should be changed to > primary_port_name, per the standards terms. However, as this is > meaningful only to a FC/NPIV savvy person - it may be better to simply > have an attribute such as virtual_port=<true/false>. If false, then PPN > is the port_name. If true, then you would use the same device tree > relationship pointed out above to find out which of the peers to the > scsi_host has virtual_port=true, then you have it's port_name, port_id, > etc... Yes, it feels like a little more work, but I feel it's a better > alternative as the spread of object information internally is limited, > and the external view, which can be easily managed via scripts/tools has > as much or more information available. Again, fine with me, but due to the "flat" view of virtual adapters on Linux on zSeries I see problems to implement this. Only way to implement an hierarchical view for zfcp is to introduce a "dummy" scsi_host for the primary port ... Ouch Have to think about this for a while. 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