On Tue, May 30, 2023 at 01:18:22PM -0500, Eric Blake wrote:
> > + /* It is more convenient to manage PAYLOAD_LEN by what
was negotiated
> > + * than to require the user to have to set it correctly.
> > + * TODO: Add new h->strict bit to allow intentional protocol violation
> > + * for interoperability testing.
> > + */
> > + if (h->extended_headers)
> > + flags |= LIBNBD_CMD_FLAG_PAYLOAD_LEN;
> > + else
> > + flags &= ~LIBNBD_CMD_FLAG_PAYLOAD_LEN;
>
> Nice -- I wanted to ask for:
>
> flags &= ~(uint32_t)LIBNBD_CMD_FLAG_PAYLOAD_LEN;
>
> due to LIBNBD_CMD_FLAG_PAYLOAD_LEN having type "int".
>
> However: in patch#3, what has type "int" is:
>
> +#define NBD_CMD_FLAG_PAYLOAD_LEN (1<<5)
>
> and here we have LIBNBD_CMD_FLAG_PAYLOAD_LEN instead -- and the latter
> has type unsigned int already, from your recent commit 69eecae2c03a
> ("api: Generate flag values as unsigned", 2022-11-11).
Still, worth a (separate) cleanup patch to nbd-protocol.h to prefer
unsigned constants for the flag values where they are not generated.
I pushed a preliminary commit 65011cf6 for libnbd along those lines,
and will copy the same changes to nbd-protocol.h over to nbdkit
shortly. v4 of this series will be rebased on that.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org