On 5/21/15, 3:49 PM, Chris Leech wrote:
On Wed, May 13, 2015 at 03:12:45PM -0700, Chris Leech wrote:
This makes the iscsi_host, iscsi_session, iscsi_connection, and
iscsi_endpoint transport class devices only visible in sysfs under a
matching network namespace. The network namespace for all of these
objects is tracked in the iscsi_cls_host structure.
I noticed that I didn't change iscsi_iface, but it should probably be
handled the same was as iscsi_endpoint.
I had intentionally skipped over all the flashnode stuff, until I had a
chance to go back and take a closer look.
Is there any particular reason why the flashnode support was implemented
as a bus? Following the pattern of everything else in
scsi_transport_iscsi it should probably have been two classes
(iscsi_flash_session and iscsi_flash_conn). It's an issue as sysfs
tagging only works on a per-class basis right now.
At some point upstream started telling us to stop using classes and use
buses instead. It was around the time the fcoe's fcoe_sysfs stuff was
being reviewed. In the middle of this mail is the comment about using
buses instead of classes for fcoe:
http://www.spinics.net/lists/linux-scsi/msg58168.html
I can see a couple of ways forward.
1) Extend sysfs tagging to work with device_type as well as class, and
use that for the two types on the flashnode "bus"
If we are supposed to be using buses instead of classes then I think is
correct.
2) Change the flashnode code to use classes instead of a bus.
Keeping a single iscsi_flashnode class and continuing to use the two
device_types for sessions and connections should result in the only
visible change being /sys/bus/iscsi_flashnode moving to
/sys/class/iscsi_flashnode.
If we can use classes, this is fine with me.
I prefer #2, but it looks like the open-iscsi tools would need to be
updated (not all code paths follow the recommendations to ignore
bus/class differences and check all subsystem locations). And I don't
know for sure that there aren't any other tools using this interface
(it's only implemented for qla4xxx).
Ccing qlogic. I do not think any tools use it. I do not even know if
anyone uses iscsiadm to manage it. Qlogic?
--
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
