Proposal looks good to me in principle. On Fri, Mar 22, 2019 at 10:06:29PM +0000, Richard W.M. Jones wrote: > However the original proposal you put here seems reasonable. I have > only one comment about it: Should the new error (ENOTSUP) be submitted > as a separate patch to the spec?
I don't see the need? We don't need ENOTSUP for anything else right now; our negotiation should cover all existing protocol options. > On Fri, Mar 22, 2019 at 12:17:59PM -0500, Eric Blake wrote: > > [1] https://lists.debian.org/nbd/2016/12/msg00015.html and following > > (doc: Propose NBD_FLAG_INIT_ZEROES extension) > > > > > > > > I will not push this without both: > > > - a positive review (for example, we may decide that burning another > > > NBD_FLAG_* is undesirable, and that we should instead have some sort > > > of NBD_OPT_ handshake for determining when the server supports > > > NBD_CMD_FLAG_FAST_ZERO) > > From an implementation point of view I prefer simple flags over having > to implement a brand new option. > > We can always work out how to extend the flags field if we run out of > flags. For example, by implementing NBD_OPT_INFO2 with a much bigger > flags field. My plan has always been to reserve the most significant bit in the flags field as a "there are more flags somewhere", and then add a 64-bit flag field if we run out. So yeah, I'm not too worried about running out of flags. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
