On 9/24/19 4:07 PM, Richard W.M. Jones wrote:
 Eventually nbdkit will install this as a public header file and we
 will be able to consume it from $includedir.  In the mean time
 synchronize with the copy in nbdkit.
 ---
  lib/nbd-protocol.h | 57 +++++++++++++++++++++++-----------------------
  1 file changed, 28 insertions(+), 29 deletions(-)
  
  /* Newstyle handshake OPT_EXPORT_NAME reply message. */
  struct nbd_export_name_option_reply {
    uint64_t exportsize;          /* size of export */
    uint16_t eflags;              /* per-export flags */
    char zeroes[124];             /* optional zeroes */
 -} __attribute__((packed));;
 +} NBD_ATTRIBUTE_PACKED;; 
Double ;;
  
 -/* Global flags. Exposed by the generator as LIBNBD_HANDSHAKE_FLAG_* instead
 +/* Global flags. */
  #define NBD_FLAG_FIXED_NEWSTYLE 1
  #define NBD_FLAG_NO_ZEROES      2
 - */ 
We won't be using these names in the rest of libnbd, except maybe we
should add a compile-time assertion that NBD_FLAG_FIXED_NEWSTYLE ==
LIBNBD_FLAG_FIXED_NEWSTYLE (ie. that our generator produces public
constants in <libnbd.h> that match the NBD protocol constants).
  /* New-style handshake server reply when using NBD_OPT_EXPORT_NAME.
   * Modern clients use NBD_OPT_GO instead of this.
 @@ -167,7 +167,7 @@ struct nbd_new_handshake_finish {
    uint64_t exportsize;
    uint16_t eflags;            /* per-export flags */
    char zeroes[124];           /* must be sent as zero bytes */
 -} __attribute__((packed));
 +} NBD_ATTRIBUTE_PACKED; 
Redundant type.
  
 -/* Command flags. Exposed by the generator as LIBNBD_CMD_FLAG_* instead
 -#define NBD_CMD_FLAG_FUA      (1<<0)
 -#define NBD_CMD_FLAG_NO_HOLE  (1<<1)
 -#define NBD_CMD_FLAG_DF       (1<<2)
 -#define NBD_CMD_FLAG_REQ_ONE  (1<<3)
 -*/
 +#define NBD_CMD_FLAG_FUA       (1<<0)
 +#define NBD_CMD_FLAG_NO_HOLE   (1<<1)
 +#define NBD_CMD_FLAG_DF        (1<<2)
 +#define NBD_CMD_FLAG_REQ_ONE   (1<<3)
 +#define NBD_CMD_FLAG_FAST_ZERO (1<<4) 
Another case where having compile-time assertions that our generator
matches protocol constants is probably worthwhile.
ACK to the plan for synchronizing.
-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  
qemu.org | 
libvirt.org