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