While working on improving the backend interface to allow filters
to handle errors, I noticed that I've introduced some minor
incompatibilities for filters that don't quite obey the documentation
which states that a callback should return only 0/-1. Prior to
my additions, we treated all plugin returns other than -1 as success
(sort of makes sense for a positive return, particularly if a
plugin can guarantee no short read/write and so just returns the
syscall value; a bit weirder if a plugin returns something other
than -1 on failure, where a typical case might be a plugin that
tried to return negative errno). However, I've had two commits
that were inconsistent, where a single plugin callback's
undocumented return value outside of 0/-1 was sometimes treated
as success and sometimes as failure.
We have two options: we can tighten the nbdkit code to match the
existing documentation (previously unenforced) to require that a
plugin MUST return 0 (or positive) on success (and treat
everything else as failures), which may subtly break some
existing plugins that weren't expecting this. Or we can fix the
nbdkit code to consistently always treat -1 as the only failure
value, and continue to allow -2 or positive values as
(undocumented) success.
This series goes with the latter option, but because I also see
the possibility of going with the former option, I'm not pushing
these without review.
Eric Blake (2):
plugins: Consistent error handling in zero
plugins: Consistent error handling on FUA
src/plugins.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--
2.14.3