All of lore.kernel.org
 help / color / mirror / Atom feed
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...

  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.