[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/2] Correct definition of NBD_CMD_FLAG_FUA

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 2/2] Correct definition of NBD_CMD_FLAG_FUA
Date: Thu, 31 Mar 2016 13:14:50 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1

On 03/31/2016 12:21 PM, Alex Bligh wrote:
> On 31 Mar 2016, at 19:15, Alex Bligh <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]