linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: Timur Tabi <ttabi@nvidia.com>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
	"rdunlap@infradead.org" <rdunlap@infradead.org>
Subject: Re: [PATCH] docs: debugfs: do not recommend debugfs_remove_recursive
Date: Wed, 30 Apr 2025 16:57:51 +0200	[thread overview]
Message-ID: <2025043009-grueling-pretzel-086c@gregkh> (raw)
In-Reply-To: <49df4b2db57f1a431ee18f319325306ac5d13f32.camel@nvidia.com>

On Wed, Apr 30, 2025 at 02:27:18PM +0000, Timur Tabi wrote:
> On Wed, 2025-04-30 at 09:30 +0200, gregkh@linuxfoundation.org wrote:
> > > added back in 2019, and why was that functionality *added* to
> > > debugfs_remove?
> > 
> > So we didn't have 2 functions that did the same thing and no one wanted
> > to sweep the tree and rename everything at that time?  I honestly don't
> > remember, that was tens of thousands of patches ago :)
> 
> I get that, but it seems pretty clear that at the time, the intent was to
> replace debugfs_remove_recursive() with debugfs_remove().  The C function is
> named debugfs_remove() and the macro is called debugfs_remove_recursive().
> 
> What you're saying now is that the C function should be renamed to
> debugfs_remove_recursive() and the macro should be swapped.  I don't think
> that's a good idea.

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?

Naming is hard.

> > > I recently added a patch to Nouveau that used debugfs_remove() to clean up
> > > all debugfs entries
> > > specifically because it operates recursively.
> > 
> > That's great, I'm not objecting to that, just that we need to stick with
> > one or the other and I'd prefer the "recursive" name as that makes it
> > blindingly obvious what is happening here while without it, people can
> > get confused.
> 
> Well, wouldn't you think it's confusing to call a function named
> debugfs_remove_recursive() in order to remove a single file?

As debugfs doesn't really care about files vs. directories it just
doesn't matter.

> If you want, I can change the documentation to say, "please use
> debugfs_remove_recursive() to remove directories, and debugfs_remove() to
> remove files".  

Let's just pick one and be done with it please.  Especially now that we
are reviewing the rust bindings for it, let's not end up duplicating
that mess there.

> We could also modify debugfs_remove_recursive() to issue a WARN if it is
> called on a file.

Never call WARN().  If you do, you just rebooted the box because a few
billion Linux machined have panic-on-warn enabled.

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 :)

thanks,

greg k-h

  reply	other threads:[~2025-04-30 14:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-29 17:39 [PATCH] docs: debugfs: do not recommend debugfs_remove_recursive Timur Tabi
2025-04-29 17:47 ` Greg Kroah-Hartman
2025-04-29 18:24   ` Timur Tabi
2025-04-30  7:30     ` gregkh
2025-04-30 14:27       ` Timur Tabi
2025-04-30 14:57         ` gregkh [this message]
2025-04-30 16:36           ` Timur Tabi
2025-04-30 17:10             ` gregkh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2025043009-grueling-pretzel-086c@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=ttabi@nvidia.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).