On 9/25/2024 5:53 PM, Pavel Begunkov wrote: > 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. How would you prefer it. Explicit padding (7 bytes), hint_type as u16 or anything else?
