On Wed, Feb 01, 2023 at 02:01:18PM -0800, Bart Van Assche wrote: > On 2/1/23 13:23, Luis Chamberlain wrote: > > On Wed, Feb 01, 2023 at 12:58:00PM -0800, Luis Chamberlain wrote: > > > On Mon, Jan 30, 2023 at 01:26:50PM -0800, Bart Van Assche wrote: > > > > Move the code for creating the block layer debugfs root directory into > > > > blk-mq-debugfs.c. This patch prepares for adding more debugfs > > > > initialization code by introducing the function blk_mq_debugfs_init(). > > > > > > > > Cc: Christoph Hellwig <hch@xxxxxx> > > > > Cc: Ming Lei <ming.lei@xxxxxxxxxx> > > > > Cc: Keith Busch <kbusch@xxxxxxxxxx> > > > > Signed-off-by: Bart Van Assche <bvanassche@xxxxxxx> > > > > > > Reviewed-by: Luis Chamberlain <mcgrof@xxxxxxxxxx> > > > > Sorry but actually a neuron triggered after this to remind me of commit > > 85e0cbbb8a ("block: create the request_queue debugfs_dir on > > registration") and so using the terminology on that commit, wouldn't > > this not create now the root block debugfs dir for request-based block > > drivers? > > Hi Luis, > > This patch should not change any behavior with CONFIG_DEBUG_FS=y. Ignore CONFIG_DEBUG_FS=y. This is about blktrace which needs it for both types of drivers. > As one can see in include/linux/debugfs.h, debugfs_create_dir() does not > create a directory with CONFIG_DEBUG_FS=n: > > static inline struct dentry *debugfs_create_dir(const char *name, > struct dentry *parent) > { > return ERR_PTR(-ENODEV); > } > > I think the only behavior change introduced by this patch is that > blk_debugfs_root remains NULL with CONFIG_DEBUG_FS=n instead of being set to > ERR_PTR(-ENODEV). My point was commit 85e0cbbb8a made blk_debugfs_root non-null always now when debugfs is enabled for both request-based block drivers and for make_request block drivers (multiqueue). My reading is that with your patch blk_debugfs_root will not be created for request-based block drivers. Luis