From: Al Viro <viro@zeniv.linux.org.uk>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-fsdevel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC][PATCH] Change calling conventions for filldir_t
Date: Tue, 16 Aug 2022 17:32:08 +0100 [thread overview]
Message-ID: <YvvGiLlrzXandedE@ZenIV> (raw)
In-Reply-To: <YvvEsGWvarSwW5kh@casper.infradead.org>
On Tue, Aug 16, 2022 at 05:24:16PM +0100, Matthew Wilcox wrote:
> > The former tended to use 0/-E... conventions - -E<something> on failure.
> > The latter tended to use 0/1, 1 being "stop, we are done".
> > The callers treated anything non-zero as "stop", ignoring which
> > non-zero value did they get.
> >
> > "true means stop" would be more natural for the second group; "true
> > means keep going" - for the first one. I tried both variants and
> > the things like
> > if allocation failed
> > something = -ENOMEM;
> > return true;
> > just looked unnatural and asking for trouble.
>
> I like it the way you have it. My only suggestion is:
>
> +++ b/include/linux/fs.h
> @@ -2039,6 +2039,7 @@ extern bool may_open_dev(const struct path *path);
> * the kernel specify what kind of dirent layout it wants to have.
> * This allows the kernel to read directories into kernel space or
> * to have different dirent layouts depending on the binary type.
> + * Return 'true' to keep going and 'false' if there are no more entries.
> */
> struct dir_context;
> typedef int (*filldir_t)(struct dir_context *, const char *, int, loff_t, u64,
OK... FWIW, an additional argument is that ->iterate() instances are
not calling those directly - they are calling dir_emit(), which returns
true for "keep going" and false for "stop". This makes the calling
conventions for callbacks match that...
next prev parent reply other threads:[~2022-08-16 16:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-16 16:11 [RFC][PATCH] Change calling conventions for filldir_t Al Viro
2022-08-16 16:24 ` Matthew Wilcox
2022-08-16 16:32 ` Al Viro [this message]
2022-08-16 16:57 ` Christian Brauner
2022-08-16 18:58 ` Linus Torvalds
2022-08-16 19:11 ` Switching to iterate_shared Matthew Wilcox
2022-08-16 19:11 ` [Ocfs2-devel] " Matthew Wilcox via Ocfs2-devel
2022-08-16 20:14 ` Jan Harkes
2022-08-16 21:20 ` Matthew Wilcox
2022-08-16 22:58 ` Linus Torvalds
2022-08-17 7:25 ` Amir Goldstein
2022-08-17 17:05 ` Linus Torvalds
2022-08-17 20:13 ` Amir Goldstein
2022-08-16 22:30 ` Casey Schaufler
2022-08-16 22:30 ` [Ocfs2-devel] " Casey Schaufler via Ocfs2-devel
2022-08-16 23:09 ` Linus Torvalds
2022-08-16 23:09 ` [Ocfs2-devel] " Linus Torvalds via Ocfs2-devel
2022-08-18 14:35 ` Matthew Wilcox
2022-08-18 14:35 ` [Ocfs2-devel] " Matthew Wilcox via Ocfs2-devel
2022-08-18 16:14 ` [apparmor] " John Johansen
2022-09-21 19:25 ` Mike Marshall
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=YvvGiLlrzXandedE@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.