From: Konstantin Shelekhin <k.shelekhin@yadro.com>
To: Mike Christie <michael.christie@oracle.com>
Cc: <target-devel@vger.kernel.org>
Subject: Re: SCSI target logs
Date: Wed, 24 May 2023 11:54:45 +0300 [thread overview]
Message-ID: <ZG3Q1eHXwnQCFbYL@yadro.com> (raw)
In-Reply-To: <91f502dc-6d31-2d09-bec4-276851221b56@oracle.com>
On Tue, May 23, 2023 at 10:40:25AM -0500, Mike Christie wrote:
> > We have MODULE_ALIAS(), so it's possible to do something similar to
> > drivers/md/raid5.c:
>
> Ah ok, nice.
>
> What is the target_core_fabric_ops->fabric_name going to be?
>
> I think that can't change or it will break userspace tools like rtslib/targetlci
> right? It would change the /sys/kernel/config/target/$fabric_name path?
Yeah, we surely can't do that.
> Do you want the module level error message to match to the fabric_name
> or the module name? I think the fabric_name is nicer, because it's what
> the users normally use to interact with the tools/kernel.
>
> Other than that, I think it's ok.
Actually the whole module renaming idea came to me after studying the
NVMe target code, because of how neatly the module names reflect the
code units. As for the SCSI target, maybe instead of using module names
we can do something similar to what device mapper does with DM_PREFIX
and get away with simply stating this in core modules:
TARGET_PREFIX core
This in fabric modules:
TARGET_PREFIX <fabric-name>
And this in backstore modules:
TARGET_PREFIX <bs-name>
So the resulting messages would be something like this:
target_err("This module blew up\n")
[Thu May 11 00:00:00 2023] target iser: This module blew up
target_sess_err(&se_sess, "Waiting for running cmds to complete.\n")
[Thu May 11 00:00:00 2023] target iscsi [iqn.2023-01.com.example:blah-blah -> 10]: Waiting for running cmds to complete.
We can do the very same thing with this:
pr_fmt(fmt) "target <fabric-name>": fmt
but then we will have one extra ":" here:
target_sess_err(&se_sess, "Waiting for running cmds to complete.\n")
[Thu May 11 00:00:00 2023] target iscsi: [iqn.2023-01.com.example:blah-blah -> 10]: Waiting for running cmds to complete.
Dunno how much of an OCD issue this is :D
next prev parent reply other threads:[~2023-05-24 8:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 15:40 SCSI target logs Konstantin Shelekhin
2023-05-20 17:56 ` Mike Christie
2023-05-21 9:36 ` Konstantin Shelekhin
2023-05-23 15:40 ` Mike Christie
2023-05-24 8:54 ` Konstantin Shelekhin [this message]
2023-05-24 13:57 ` Konstantin Shelekhin
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=ZG3Q1eHXwnQCFbYL@yadro.com \
--to=k.shelekhin@yadro.com \
--cc=michael.christie@oracle.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.