On Wed, Nov 02, 2022 at 01:43:13PM +0000, Richard W.M. Jones wrote: > On Tue, Nov 01, 2022 at 02:56:09PM -0500, Eric Blake wrote: > ... > > +=item S<6> > > + > > +Triggers a call to the C function C<nbdkit_disconnect> with C<force> > > +set to false, which requests a soft disconnect of the current client > > +(future client requests are rejected with C<ESHUTDOWN> without calling > > +into the plugin, but current requests may complete). Since the client > > +will likely get the response to this command, nbdkit then treats empty > > +stderr as success for the current callback, and parses non-empty > > +stderr as if the script had exited with code S<1>. > > OK .. seems like complicated behaviour, but I can sort of see the > reasoning behind it. > > I do wonder if we just want to use separate codes for the "soft > disconnect + OK" and the "soft disconnect + error" cases. We have > reserved more so we won't run out :-)
Given that both you and Laszlo requested it, I will respin along those lines. > > > +=item 7-15 > > + > > +These exit codes are reserved for future use. Note that versions of > > +nbdkit E<lt> 1.34 documented that codes S<8> through S<15> behaved > > This is actually a case where S<> around the nbdkit E<lt> 1.34 makes > sense. But it should be removed around S<8> etc and in the next line > below. I'll fix the pre-existing inconsistent use of S<> as part of the respin. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
