On 9/25/24 14:21, Kanchan Joshi wrote:
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?
Explicit padding is better than the current version. Ideally,
I'd like the new fields gone (e.g. if it goes in the direction
of per file hints) or prefer to minimise the size and make the
leftover padding reusable, but that depends on what the feature
needs to be extendable.
And what hint types do we expect in the future? Another question,
don't we want an apui that allows to pass multiple hints? Quite
similar to what I asked about "meta" rw, and it might actually
make a lot of sense to combine them into common infra, like what
cmsg is for networking.
meta[] = [ {INTEGRITY, integrity_params},
{write_hint, ...},
...];
Even though an actual impl would need to be a bit more elaborated.
--
Pavel Begunkov
