aboutsummaryrefslogtreecommitdiff
path: root/fs/omfs
diff options
context:
space:
mode:
authorAl Viro2022-08-16 11:57:56 -0400
committerAl Viro2022-08-17 17:25:04 -0400
commit25885a35a72007cf28ec5f9ba7169c5c798f7167 (patch)
tree948589bcdf9420b67123d83eab2cf7f7d8bdbcf8 /fs/omfs
parentd6da19c9cace63290ccfccb1fc35151ffefc0bec (diff)
Change calling conventions for filldir_t
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>
Diffstat (limited to 'fs/omfs')
0 files changed, 0 insertions, 0 deletions