FC bus questions

Hi James (and everyone else),

I wanted to continue the discussion on FCoE statistics and a possible
device tree reorganization. The original thread has been expired from my mail system, so I have to start this new thread. The main theme was that we might want to convert FC to be a bus.

For reference here is your proposed sysfs layout-

/sys/.../fcportX/fcfportY/fcfabricZ/fcvportA/fcrportB

                                            /fcpinitC/hostD/target<H:C:T>/<H:C:T>

I can see a benefit to extending the FC device tree. Assuming that
each of these devices is created as they're discovered by the FC HBA then it's giving a more accurate description of the system's state. For example, in FCoE if you were to succeed with FIP and discover a FCF, but the FLOGI failed then user space could clearly see that devices were only created up to the fcfabric. I also think that it simply makes more room for new attributes. With FCFs and FCoE attributes it would be nice to have them better organized instead of just grouping them all under the fc_host.

Aside from a sysfs reorganization, which could be done without making
FC a bus, the main benefit seems to be that other FC4 protocols could use a FC HBA. Is there other goodness that I'm overlooking?

Also, buses usually have devices and drivers. I'm not sure what the
FC drivers would be since SCSI would ultimately provide the drivers for SCSI-FCP. Would a FC bus only have devices and no drivers?

Thanks, //Rob

Yes. I feel treating FC as bus make better understanding then host. This clearly has advantages.

Various FCoE attributes which are basically NIC specific but belongs to FCoE from protocol perspective can be grouped under FCoE directory to start with.

Adding different FC4 protocols under FC HBA was not giving right sense from complete system perspective. For ex: adding FCoE specific information in FC HBA. I feel the other approach will give much clarity.

The 2 main gripes I hoped it would solve are:

- Right now, FC things always have a scsi_host "hostD" object that binds to the physical parent (usually the pci adapter object), then the fc objects appear under it. This relationship is very odd - especially if the fc-thing isn't acting as an fcp initiator, or if the sub-objects are scsi-hosts in their own right. And the fact its the location of driver-specific attributes makes it further odd (why is one scsi_host different from another - why aren't the driver-specific attributes on the pci adapter object instead).

- As you point out - much better clarity and organization of attributes and a better representation of bus/connectivity heirarchy.

I probably took too much latitude with the word "bus", as I was thinking more toward the sysfs object tree rather than the linux bus/device/driver relationships. Yes, it probably means no drivers as it should be as light as possible. I think of this as a fancy "driver" that creates it's own sub-objects, using the transport to do all the "fancy" work for the driver and in a single manner for all drivers. Fundamentally moves the scsi_host binding to a different place, and the correlations to class objects as well.

Thinking about the recent DMA issues with scsi - scsi should make every scsi_host convert over to the specifying a physical dma parent when it does scsi_add_host().

-- james s