Re: [PATCH] docs: debugfs: do not recommend debugfs_remove_recursive

["gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>]

On Wed, Apr 30, 2025 at 04:36:04PM +0000, Timur Tabi wrote:
> On Wed, 2025-04-30 at 16:57 +0200, gregkh@linuxfoundation.org wrote:
> > I don't really remember what we were talking about in 2019 for this, but
> > look at how many of each there are in the tree:
> > 	402	debugfs_remove
> > 	627	debugfs_remove_recursive
> > 
> > so we need to pick one and just stick to it.  Majority wins?  Shortest
> > function name wins?  Most descriptive winse?
> 
> How about "intent of the original patch wins"?  I'm pretty sure that if my patch had been merged in
> 2019, these numbers would be swapped.

5.4.0 came out in 2019, and the numbers there are:
	402	debugfs_remove
	461	debugfs_remove_recursive
So not quite.


But we are both ignoring debugfs_lookup_and_remove(), which I do
recommend people using over _both_ of those as there's no need to keep
anything around in the driver at all.

So that proves that you are right, and I'm wrong, as there is no
debugfs_lookup_and_remove_recursive()

> > So I'll defer to you, which one do you want?  You originally said
> > debugfs_remove(), which is fine, but you get to send a patch touching
> > all of those files :)
> 
> If you really want me to send out a patch modifying 600+ calls, I will, but I think that will cause
> more harm than good, and I'll just make more enemies than friends.  

A sed script for Linus at -rc1 is usually a good way to do this, but I
can throw some interns at it as well.  Or I can script it on my side and
just do a big push in one of my trees.

> All I was trying to do with my patch was have the documentation align with the code.  This would be
> a low-impact first step to replacing debugfs_remove_recursive with debugfs_remove everywhere.

Ok, fair enough, I'm now convinced, I'll go take your patch now, sorry
for the noise, but thanks for the discussion.

greg k-h