All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Al Viro <viro@zeniv.linux.org.uk>
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:24:16 +0100	[thread overview]
Message-ID: <YvvEsGWvarSwW5kh@casper.infradead.org> (raw)
In-Reply-To: <YvvBs+7YUcrzwV1a@ZenIV>

On Tue, Aug 16, 2022 at 05:11:31PM +0100, Al Viro wrote:
> filldir_t instances (directory iterators callbacks) used to return 0 for
> "OK, keep going" or -E... for "stop".  Note that it's *NOT* how the
> error values are reported - the rules for those are callback-dependent
> and ->iterate{,_shared}() instances only care about zero vs. non-zero
> (look at emit_dir() and friends).
> 
> So let's just return bool ("should we keep going?") - it's less confusing
> that way.  The choice between "true means keep going" and "true means
> stop" is bikesheddable; we have two groups of callbacks -
>     do something for everything in directory, until we run into problem
> and
>     find an entry in directory and do something to it.
> 
> 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,

> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 9eced4cc286e..8b8c0c11afec 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2040,7 +2040,7 @@ umode_t mode_strip_sgid(struct user_namespace *mnt_userns,
>   * to have different dirent layouts depending on the binary type.
>   */
>  struct dir_context;
> -typedef int (*filldir_t)(struct dir_context *, const char *, int, loff_t, u64,
> +typedef bool (*filldir_t)(struct dir_context *, const char *, int, loff_t, u64,
>  			 unsigned);
>  
>  struct dir_context {

  reply	other threads:[~2022-08-16 16:24 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 [this message]
2022-08-16 16:32   ` Al Viro
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=YvvEsGWvarSwW5kh@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --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 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.