On 9/25/24 12:09, Kanchan Joshi wrote:
On 9/25/2024 11:27 AM, Hannes Reinecke wrote:
...
As it stands the new struct will introduce
a hole of 24 bytes after 'hint_type'.
This gets implicitly padded at this point [1][2], and overall size is
still capped by largest struct (which is of 16 bytes, placed just above
this).
For me it's about having hardly usable in the future by anyone else
7 bytes of space or how much that will be. Try to add another field
using those bytes and endianess will start messing with you. And 7
bytes is not that convenient.
I have same problem with how commands were merged while I was not
looking. There was no explicit padding, and it split u64 into u32
and implicit padding, so no apps can use the space to put a pointer
anymore while there was a much better option of using one of existing
4B fields.
[1] On 64bit
» union {
» » struct {
» » » __u64 addr3; /* 48 8 */
» » » __u64 __pad2[1]; /* 56 8 */
» » }; /* 48 16 */
» » struct {
» » » __u64 hint_val; /* 48 8 */
» » » __u8 hint_type; /* 56 1 */
» » }; /* 48 16 */
» » __u64 optval; /* 48 8 */
» » __u8 cmd[0]; /* 48 0 */
» }; /* 48 16 */
» /* size: 64, cachelines: 1, members: 13 */
[2] On 32bit
» union {
» » struct {
» » » __u64 addr3; /* 48 8 */
» » » __u64 __pad2[1]; /* 56 8 */
» » }; /* 48 16 */
» » struct {
» » » __u64 hint_val; /* 48 8 */
» » » __u8 hint_type; /* 56 1 */
» » }; /* 48 12 */
» » __u64 optval; /* 48 8 */
» » __u8 cmd[0]; /* 48 0 */
» }; /* 48 16 */
» /* size: 64, cachelines: 1, members: 13 */
};
--
Pavel Begunkov
