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
