mirror of
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
synced 2025-10-27 00:45:37 +10:00
25885a35a7
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.
[folded suggestion from Matthew Wilcox <willy@infradead.org>]
Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
||
|---|---|---|
| .. | ||
| agheader_repair.c | ||
| agheader.c | ||
| alloc.c | ||
| attr.c | ||
| attr.h | ||
| bitmap.c | ||
| bitmap.h | ||
| bmap.c | ||
| btree.c | ||
| btree.h | ||
| common.c | ||
| common.h | ||
| dabtree.c | ||
| dabtree.h | ||
| dir.c | ||
| fscounters.c | ||
| health.c | ||
| health.h | ||
| ialloc.c | ||
| inode.c | ||
| parent.c | ||
| quota.c | ||
| refcount.c | ||
| repair.c | ||
| repair.h | ||
| rmap.c | ||
| rtbitmap.c | ||
| scrub.c | ||
| scrub.h | ||
| symlink.c | ||
| trace.c | ||
| trace.h | ||
| xfs_scrub.h | ||