[PATCH 0/1] nvmet: View subsystem connections on nvmeof target

[Hannes Reinecke]

On 9/20/23 17:36, Redouane BOUFENGHOUR wrote:
> You can find the path here
> https://lore.kernel.org/linux-nvme/20230920141205.26637-2-redouane.boufenghour@shadow.tech/
> 
> We chose to put the information in the configfs for nvmet which takes
> up the spirit of the "target" module for connection information.
> 
> In my humble opinion, this information would be better located in the
> sysfs so the kernel provides the info to userland. That being said,
> splitting the source of truth for the nvmet module into two separate
> pseudo-fs could generate some confusion which would make it harder to
> users to find all available informations provided by the nvmet module.
> This is one of the reason why in the "target" module this whole ordeal
> is handled by a 2-step procedure: first, userland creates ACLs
> directory (since we can't create a directory in the configfs from the
> kernel) based on an attr filling "dynamic_sessions" and then the
> kernel module fills the info in a dedicated configfs attr page in the
> created directory. (The "target" implementation is available in
> drivers/target/iscsi/iscsi_target_configfs.c in the
> lio_target_tpg_dynamic_sessions_show function)
> 
> To sum it up, I think it all boils down to the question: Do you want
> to maintain some similarities between target and nvmet modules or
> should the nvmet module go its own way and implement this in a
> different way ?
> 
Thing is, 'configfs' is, as the name implied, for configuration. Having 
the driver fill out information is not something the user can nor should 
edit, and as such it's arguably wrong to have this information in configfs.
You do have a point in that this information might be displayed in 
sysfs, but sysfs is pretty tied to the driver model (ie 'struct 
device'). And nvmet does not use 'struct device' internally, so really 
sysfs is not a good fit, either.
debugfs, OTOH, is pretty good fit, as this is information internal to 
the nvmet subsystem. And one can trivially avoid displaying that 
information by simply not mounting debugfs, thereby maintaining
backwards compability.

So I guess debugfs is it, even if it's more work.
Plus you can use the 'seq_file' interface to avoid the page size 
limitation when printing out data.

And I really would like to have this information, too, as occasionally
I've foud to have a need for that information, too.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare at suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman