On Wed, Apr 30, 2025 at 04:36:04PM +0000, Timur Tabi wrote: > On Wed, 2025-04-30 at 16:57 +0200, gregkh@xxxxxxxxxxxxxxxxxxx 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
