search for: nbdkit_set_errno

On Tue, Jan 24, 2017 at 03:16:45PM +0000, Richard W.M. Jones wrote: > However we could add another API: > > nbdkit_set_errno (int errno); > > This allows the plugin to send the errno back to the core code > explicitly. It's effectively stored as a global in the core code. What I'm really saying here is that at the moment (after your previous patch series) we have an implicit channel where errno is pas...

...l plugin seeing a system call fail, and that plugin callback returning to nbdkit code, and any of that code might touch errno. Since some of that code would be in the language interpreter, we cannot even be careful about preserving errno along those paths. So I think if the caller didn't call nbdkit_set_errno, we should assume no errno value is available for us to use. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many power...

On 01/24/2017 05:38 AM, Richard W.M. Jones wrote: > On Mon, Jan 23, 2017 at 09:13:23PM -0600, Eric Blake wrote: >> Begin the language binding followups to my new .zero callback, since >> Rich was indeed correct that we want them. >> >> I'm more familiar with python and perl (at least to the point that >> I was able to modify the appropriate example files and

...This would continue to work fine, but new code which cared about the > errno could do this instead: > > sub pread > { > my $h = shift; > my $count = shift; > my $offset = shift; > my $ret; > read ($FH, $ret, $count, $offset) || { > nbdkit_set_errno (POSIX::errno ()); > die "read: $!" > } > return $ret; > } Except I can't even figure out how to expose nbdkit_set_error (hmm, I named it set_error instead of set_errno in my v2 series) to the perl code. In fact, with just this change to example.pl: d...

...is to review the way that plugins set errors. Currently there is only one call (nbdkit_error) which takes a string. Thus if the plugin error comes with an errno, it is effectively lost (or at best, turned into a string, but not in a way that callers can use). However we could add another API: nbdkit_set_errno (int errno); This allows the plugin to send the errno back to the core code explicitly. It's effectively stored as a global in the core code. Note that the correct calling sequence from C is: nbdkit_set_error (errno); // this call is optional and may be omitted nbdkit_error ("oops...

On 01/24/2017 09:41 AM, Richard W.M. Jones wrote: > On Tue, Jan 24, 2017 at 03:16:45PM +0000, Richard W.M. Jones wrote: >> However we could add another API: >> >> nbdkit_set_errno (int errno); >> >> This allows the plugin to send the errno back to the core code >> explicitly. It's effectively stored as a global in the core code. > > What I'm really saying here is that at the moment (after your previous > patch series) we have an implicit...

...rning to > nbdkit code, and any of that code might touch errno. Since some of > that code would be in the language interpreter, we cannot even be > careful about preserving errno along those paths. Indeed - so it is a pre-existing bug. > > So I think if the caller didn't call nbdkit_set_errno, we should > assume no errno value is available for us to use. Completely avoiding errno will make little difference to language binding plugins (errors will now default to EIO instead of errno if nbdkit_set_error() was not called, but even that error is still almost always wrong); but it will...

On Tue, Jan 24, 2017 at 10:36:43AM -0600, Eric Blake wrote: > On 01/24/2017 09:41 AM, Richard W.M. Jones wrote: > > On Tue, Jan 24, 2017 at 03:16:45PM +0000, Richard W.M. Jones wrote: > >> However we could add another API: > >> > >> nbdkit_set_errno (int errno); > >> > >> This allows the plugin to send the errno back to the core code > >> explicitly. It's effectively stored as a global in the core code. > > > > What I'm really saying here is that at the moment (after your previous > > patc...

..., we cannot even be > > careful about preserving errno along those paths. > > Indeed - so it is a pre-existing bug. Hmm, good point. I forgot that we were using errno even before 19184d3e. Well I guess the patch is OK in that case. > > So I think if the caller didn't call nbdkit_set_errno, we should > > assume no errno value is available for us to use. > > Completely avoiding errno will make little difference to language > binding plugins (errors will now default to EIO instead of errno if > nbdkit_set_error() was not called, but even that error is still almost &g...

Fix some things I noticed while reviewing v1, and follow Rich's idea to add a new nbdkit_set_error() utility function with a binding for Python users to request a particular error (rather than being forced to live with whatever stale value is in errno after all the intermediate binding glue code). I could not easily find out how to register a C function callable from perl bindings, and have