On 6/25/19 4:13 AM, Richard W.M. Jones wrote:
On Thu, Jun 20, 2019 at 08:45:05PM -0500, Eric Blake wrote:
If any callback fails, and if no prior error was set, then the callback's failure becomes the failure reason for the overall read. (Note that this is different from the block status callback, which for now quits using the callback on subsequent chunks if an earlier chunk failed - we may decide to change one or the other for consistency before the API is stable.)
Nothing actually passes a callback function yet, so for now this is no functional change; but this will make it possible for the next patch to add an 'nbd_aio_pread_structred' API.
I don't think non-C callbacks will be able to reliably set errno, but that's something we can solve in future. Therefore ACK.
Perhaps we could change the API to: cmd->cb.fn.read (cmd->cb.opaque, cmd->data, cmd->count, cmd->offset, &error, LIBNBD_READ_XXX) where the caller is not only passed the current error, but also can store into that variable to affect the return error (rather than the return error being implied from whatever is left in errno). Of course, that necessitates passing a pointer to an integer to the callback, rather than a bare integer, so it requires a bit more surgery to the generator. And it may still not be the best interface for other language bindings - for example, I'm not sure how python would represent an in/out pointer to integer. In nbdkit, the solution was that we had a utility function nbdkit_set_error() which was more easily bound to other languages; the various plugins then declare whether they can reliably set errno, or whether errno is unreliable and nbdkit_set_error() should be the sole source of requested error status instead. So the similar interface here is that callbacks are always passed just a bare integer on input, and then call a utility function to request a specific error on output (where we then have a way to decide whether to use the value in errno, or just a hard-coded default, if the utility function was not called). As we are free to change API at a later date up until we declare stable API, I'm going ahead and pushing this one as-is. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org