Hello kernel hackers,
I noticed that in [linux]/include/uapi/linux/nbd.h the structure
struct nbd_request { __be32 magic; __be32 type; /* == READ || == WRITE */ char handle[8]; __be64 from; __be32 len; } __attribute__((packed));
is packed
Given a target where ABI requires types to be aligned on their size (1 => 1, 2 => 2, 4 => 4, 8 => 8, etc.) 4 + 4 + 8 + 8 + 4 = 28 bytes To satisfy __be64 alignement (the strictest), it must be aligned on a 8 bytes boundary, but 28 is not multiple of 8. 32 is. Padding is required. [The padding is required so that in a array of struct nbd_request[], all members of all structures are aligned to their requirement alignement]
but its reply counter part
struct nbd_reply { __be32 magic; __be32 error; /* 0 = ok, else error */ char handle[8]; /* handle you got from request */ };
4 + 4 + 8 = 16 bytes. To satisfy __be32 alignement (the strictest), it must be aligned on a 4 bytes boundary and 16 is a multiple of 4: no need for padding.
is not. Since Linux seems to read sizeof(nbd_reply) bytes from the network (see [1]), the number of bytes read varies with the number of bytes of the structure.
It won't.
So my understanding is that if the size of struct nbd_reply varies from platform/compiler to another that means trouble. I wonder:
- Is there anything about struct nbd_reply that would keep its size equal everywhere or a reason why variance in size is no problem here?
- Any ideas for a platform where you would expect struct nbd_reply to be other than 4 + 4 + 8 = 16 bytes in size?
Look for an ABI that require 'char' with either property: - size > 1 byte - alignment > 8 (16 bytes !) Regards. -- Yann Droneaud OPTEYA