All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Mike Christie <mchristi@redhat.com>
Cc: bvanassche@acm.org, bstroesser@ts.fujitsu.com,
	martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
	target-devel@vger.kernel.org, Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH 11/15] target: add sysfs support
Date: Tue, 12 May 2020 07:54:42 +0200	[thread overview]
Message-ID: <20200512055442.GA3505885@kroah.com> (raw)
In-Reply-To: <aad8269e-f9ee-ebc7-6e54-aa4b5b6021b8@redhat.com>

On Mon, May 11, 2020 at 12:15:12PM -0500, Mike Christie wrote:
> 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.

Then fix that and everything shows up automatically "for free".

> 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 :)

file systems are not devices with busses and drivers :)

> And, I can move the code to device structs, but had a question about the
> deep tree question.

Don't do it.

> 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.

Again, a "deep tree" with raw kobjects will be invisible to the normal
userspace tools that monitor changes in sysfs for devices because they
will not notice them at all.

> 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.

There should not be any difference in "speed" for something like that,
it's an in-ram filesystem with no i/o times.

> Will a deep tree be ok for this type of reason?

Nope :(

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Mike Christie <mchristi@redhat.com>
Cc: bvanassche@acm.org, bstroesser@ts.fujitsu.com,
	martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
	target-devel@vger.kernel.org, Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH 11/15] target: add sysfs support
Date: Tue, 12 May 2020 05:54:42 +0000	[thread overview]
Message-ID: <20200512055442.GA3505885@kroah.com> (raw)
In-Reply-To: <aad8269e-f9ee-ebc7-6e54-aa4b5b6021b8@redhat.com>

On Mon, May 11, 2020 at 12:15:12PM -0500, Mike Christie wrote:
> 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.

Then fix that and everything shows up automatically "for free".

> 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 :)

file systems are not devices with busses and drivers :)

> And, I can move the code to device structs, but had a question about the
> deep tree question.

Don't do it.

> 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.

Again, a "deep tree" with raw kobjects will be invisible to the normal
userspace tools that monitor changes in sysfs for devices because they
will not notice them at all.

> 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.

There should not be any difference in "speed" for something like that,
it's an in-ram filesystem with no i/o times.

> Will a deep tree be ok for this type of reason?

Nope :(

greg k-h

  reply	other threads:[~2020-05-12  8:28 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-10 21:57 [PATCH v5 00/15] target: add sysfs support Mike Christie
2020-05-10 21:57 ` Mike Christie
2020-05-10 21:57 ` [PATCH 01/15] target: check enforce_pr_isids during registration Mike Christie
2020-05-10 21:57   ` Mike Christie
2020-05-11  6:08   ` Hannes Reinecke
2020-05-11  6:08     ` Hannes Reinecke
2020-05-13 20:55   ` Lee Duncan
2020-05-13 20:55     ` Lee Duncan
2020-05-10 21:57 ` [PATCH 02/15] target: separate acl name from port ids Mike Christie
2020-05-10 21:57   ` Mike Christie
2020-05-11  6:09   ` Hannes Reinecke
2020-05-11  6:09     ` Hannes Reinecke
2020-05-13 23:35   ` Lee Duncan
2020-05-13 23:35     ` Lee Duncan
2020-05-10 21:57 ` [PATCH 03/15] target: add helper to parse acl and transport name Mike Christie
2020-05-10 21:57   ` Mike Christie
2020-05-11  6:09   ` Hannes Reinecke
2020-05-11  6:09     ` Hannes Reinecke
2020-05-11 18:22   ` Bodo Stroesser
2020-05-11 18:22     ` Bodo Stroesser
2020-05-11 21:04     ` Mike Christie
2020-05-11 21:04       ` Mike Christie
2020-05-13 23:57   ` Lee Duncan
2020-05-13 23:57     ` Lee Duncan
2020-05-10 21:57 ` [PATCH 04/15] tcm loop: use target_parse_emulated_name Mike Christie
2020-05-10 21:57   ` Mike Christie
2020-05-11  6:10   ` Hannes Reinecke
2020-05-11  6:10     ` Hannes Reinecke
2020-05-13 23:59   ` Lee Duncan
2020-05-13 23:59     ` Lee Duncan
2020-05-10 21:57 ` [PATCH 05/15] vhost scsi: " Mike Christie
2020-05-10 21:57   ` Mike Christie
2020-05-11  6:11   ` Hannes Reinecke
2020-05-11  6:11     ` Hannes Reinecke
2020-05-10 21:57 ` [PATCH 06/15] xen scsiback: " Mike Christie
2020-05-10 21:57   ` Mike Christie
2020-05-11  6:11   ` Hannes Reinecke
2020-05-11  6:11     ` Hannes Reinecke
2020-05-11  6:16   ` Jürgen Groß
2020-05-11  6:16     ` Jürgen Groß
2020-05-10 21:57 ` [PATCH 07/15] iscsi target: setup transport_id Mike Christie
2020-05-10 21:57   ` Mike Christie
2020-05-11  6:12   ` Hannes Reinecke
2020-05-11  6:12     ` Hannes Reinecke
2020-05-10 21:57 ` [PATCH 08/15] target: use tpt_id in target_stat_iport_port_ident_show Mike Christie
2020-05-10 21:57   ` Mike Christie
2020-05-11  6:13   ` Hannes Reinecke
2020-05-11  6:13     ` Hannes Reinecke
2020-05-10 21:57 ` [PATCH 09/15] target: drop sess_get_initiator_sid from PR code Mike Christie
2020-05-10 21:57   ` Mike Christie
2020-05-11  6:13   ` Hannes Reinecke
2020-05-11  6:13     ` Hannes Reinecke
2020-05-10 21:57 ` [PATCH 10/15] target: drop sess_get_initiator_sid Mike Christie
2020-05-10 21:57   ` Mike Christie
2020-05-11  6:14   ` Hannes Reinecke
2020-05-11  6:14     ` Hannes Reinecke
2020-05-10 21:57 ` [PATCH 11/15] target: add sysfs support Mike Christie
2020-05-10 21:57   ` Mike Christie
2020-05-11  6:21   ` Hannes Reinecke
2020-05-11  6:21     ` Hannes Reinecke
2020-05-11  6:30   ` Greg Kroah-Hartman
2020-05-11  6:30     ` Greg Kroah-Hartman
2020-05-11 17:15     ` Mike Christie
2020-05-11 17:15       ` Mike Christie
2020-05-12  5:54       ` Greg Kroah-Hartman [this message]
2020-05-12  5:54         ` Greg Kroah-Hartman
2020-05-10 21:57 ` [PATCH 12/15] target: add sysfs session helper functions Mike Christie
2020-05-10 21:57   ` Mike Christie
2020-05-11 18:39   ` Bodo Stroesser
2020-05-11 18:39     ` Bodo Stroesser
2020-05-11 19:21     ` Bart Van Assche
2020-05-11 19:21       ` Bart Van Assche
2020-05-11 20:16       ` Mike Christie
2020-05-11 20:16         ` Mike Christie
2020-05-12 11:19         ` Bodo Stroesser
2020-05-12 11:19           ` Bodo Stroesser
2020-05-12 15:55           ` Mike Christie
2020-05-12 15:55             ` Mike Christie
2020-05-10 21:57 ` [PATCH 13/15] target: add target_setup_session sysfs support Mike Christie
2020-05-10 21:57   ` Mike Christie
2020-05-10 21:57 ` [PATCH 14/15] iscsi target: use session sysfs helpers Mike Christie
2020-05-10 21:57   ` Mike Christie
2020-05-10 21:57 ` [PATCH 15/15] target: drop sess_get_index Mike Christie
2020-05-10 21:57   ` Mike Christie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200512055442.GA3505885@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=bstroesser@ts.fujitsu.com \
    --cc=bvanassche@acm.org \
    --cc=hare@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=mchristi@redhat.com \
    --cc=target-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.