On 03/31/2016 12:21 PM, Alex Bligh wrote: > > On 31 Mar 2016, at 19:15, Alex Bligh <alex@...872...> wrote: > >> It is doubtful whether anyone is using NBD_CMD_FLAG_FUA >> at the moment in any case. > > Drat. I spoke too soon. Qemu uses it, but presumably from its > own .h file. Yes, qemu has its own nbd.h, which still has nbd_request with a single uint32_type that holds both flags and command type. It wouldn't be too hard to rework that to more closely match upstream NBD. > > However, it's now nonsensical having it defined as 1<<16 in a > 16 bit flags variable. I don't see any problem with your patch on the NBD project side of things; it's not like 'make install' is dumping a header into /usr/include for client programs to reuse (which is _why_ qemu is using its own nbd.h), because no one has really churned out an NBD-client library for embedding in larger programs. > > Should we produce a new name for it (and future command flags) > that aren't shifted left 16 places, and just maintain the > current value for compatibility? I don't see the point. Your fix looks correct. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature