> 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
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
