From: Linus Torvalds <[email protected]>
To: Christian Brauner <[email protected]>
Cc: Dmitry Kadashev <[email protected]>,
Jens Axboe <[email protected]>,
Alexander Viro <[email protected]>,
linux-fsdevel <[email protected]>,
io-uring <[email protected]>
Subject: Re: [PATCH 1/7] namei: clean up do_rmdir retry logic
Date: Tue, 13 Jul 2021 09:57:42 -0700 [thread overview]
Message-ID: <CAHk-=wjJeGY0FAs+WLaz-cxjhYcYvF1UXtZVmqoLbZH0jqn0Qg@mail.gmail.com> (raw)
In-Reply-To: <20210713145341.lngtd5g3p6zf5eoo@wittgenstein>
On Tue, Jul 13, 2021 at 7:53 AM Christian Brauner
<[email protected]> wrote:
>
> Instead of naming all these $something_helper I would follow the
> underscore naming pattern we usually do, i.e. instead of e.g.
> rmdir_helper do __rmdir() or __do_rmdir().
That's certainly a pattern we have, but I don't necessarily love it.
It would be even better if we'd have names that actually explain
what/why the abstraction exists. In this case, it's the "possibly
retry due to ESTALE", but I have no idea how to sanely name that.
Making it "try_rmdir()" or something like that is the best I can come
up with right now.
On a similar note, the existing "do_rmdir()" and friends aren't
wonderful names either, but we expose that name out so changing it is
probably not worth it. But right now we have "vfs_rmdir()" and
"do_rmdir()", and they are just different levels of the "rmdir stack",
without the name really describing where in the stack they are.
Naming is hard, and I don't think the double underscores have been
wonderful either.
Linus
next prev parent reply other threads:[~2021-07-13 16:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-12 12:36 [PATCH 0/7] namei: clean up retry logic in various do_* functions Dmitry Kadashev
2021-07-12 12:36 ` [PATCH 1/7] namei: clean up do_rmdir retry logic Dmitry Kadashev
2021-07-13 14:53 ` Christian Brauner
2021-07-13 16:57 ` Linus Torvalds [this message]
2021-07-15 10:38 ` Dmitry Kadashev
2021-07-12 12:36 ` [PATCH 2/7] namei: clean up do_unlinkat " Dmitry Kadashev
2021-07-12 12:36 ` [PATCH 3/7] namei: clean up do_mkdirat " Dmitry Kadashev
2021-07-12 12:36 ` [PATCH 4/7] namei: clean up do_mknodat " Dmitry Kadashev
2021-07-12 18:46 ` Linus Torvalds
2021-07-12 12:36 ` [PATCH 5/7] namei: clean up do_symlinkat " Dmitry Kadashev
2021-07-12 18:54 ` Linus Torvalds
2021-07-12 12:36 ` [PATCH 6/7] namei: clean up do_linkat " Dmitry Kadashev
2021-07-12 18:57 ` Linus Torvalds
2021-07-12 12:36 ` [PATCH 7/7] namei: clean up do_renameat " Dmitry Kadashev
2021-07-12 12:41 ` [PATCH 0/7] namei: clean up retry logic in various do_* functions Dmitry Kadashev
2021-07-12 19:01 ` Linus Torvalds
2021-07-12 20:25 ` Al Viro
2021-07-13 12:28 ` Dmitry Kadashev
2021-07-13 10:22 ` Dmitry Kadashev
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='CAHk-=wjJeGY0FAs+WLaz-cxjhYcYvF1UXtZVmqoLbZH0jqn0Qg@mail.gmail.com' \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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