On 5/11/20 1:30 AM, Greg Kroah-Hartman wrote: > On Sun, May 10, 2020 at 04:57:40PM -0500, Mike Christie wrote: >> These next two patches add a sysfs interface that reports the target >> layer's I_T nexuses/sessions. For the non-SCSI people cc'd, this just means >> we are reporting a server's connections to remote clients. >> >> This patch adds the upper level dirs which shows/organizes our local port >> (tpgts below) and the connection (session below). The next patch will then >> add the dirs/files for each connection/session which exports info like >> ACL/permissions and SCSI port values. >> >> Here is the general layout: >> >> [sys]# tree scsi_target/ >> scsi_target/ >> |-- fabric/target module >> | `-- target name >> | `-- tpgt_$target_port_group_number >> | `-- sessions >> | `-- initiator name - session ID number >> | |-- acl >> | `-- transport_id >> | |-- name >> | |-- proto >> | `-- session_id >> >> Here is an example with the scsi target layer's iSCSI driver: >> >> scsi_target/ >> |-- iscsi >> | `-- iqn.1999-09.com.tcmu:minna >> | `-- tpgt_1 >> | `-- sessions >> | `-- iqn.2005-03.com.ceph:ini1-1 >> | |-- acl >> | `-- transport_id >> | |-- name >> | |-- proto >> | `-- session_id >> |-- fc >> |-- loopback >> |-- qla2xxx_tcm >> >> >> Note/Question for Greg: >> >> We are not exporting info in the upper level dirs like "fabric/target >> module", "target name", tpgt, etc and just need those dirs to be able to >> organize/view the endpoints of the session. So, in this patch I made a new >> top level dir scsi_target and made the other dirs with >> kobject_create_and_add. It looks like we could also add device structs in >> the target related structs, use classes, and build the tree/hierarchy that >> way too. It was not clear to me when to use one or the other. > > Never use kobject calls in a driver subsystem like you have here, as > those objects will not be seen by userspace tools that get uevents. > Just use real 'struct devices' if you really really need a deep > directory tree. > > But I would push back here, why do you feel you want such a deep tree? > What are you getting from this? Why do you need that "sessions" > directory at all? I do not need the sessions under the tpgt dir and will drop it. The target subsystem does not have a bus or use device structs at all right now. And, I saw how other code that does not have a bus like btrfs/ext4 use kobject_create_and_add() to group/organize objects and went wild with dirs :) And, I can move the code to device structs, but had a question about the deep tree question. A common operation will be that userspace knows the names of the objects above the session in the tree already. Apps then want to read in a specific session or scan the specific sessions in a target or a tpgt. The deep tree makes it easy to build the sysfs path and scan/read the specific object/objects. I wanted to avoid the issue where apps have with the flat layout where they have to scan every session when they just want something specific. Will a deep tree be ok for this type of reason?
