> > @@ -27,7 +27,6 @@ struct io_uring_sqe {
> > union {
> > __u64 addr; /* pointer to buffer or iovecs */
> > __u64 splice_off_in;
> > - __u16 cmd_len;
> > };
> > __u32 len; /* buffer size or number of iovecs */
> > union {
> > @@ -64,16 +63,19 @@ struct io_uring_sqe {
> > __u32 file_index;
> > };
> > union {
> > - __u64 addr3;
> > - __u64 cmd;
> > + struct {
> > + __u64 addr3;
> > + __u64 __pad2[1];
> > + } small;
>
> Thinking if this can cause any issue for existing users of addr3, i.e.
> in the userspace side? Since it needs to access this field with
> small.addr3.
> Jens - is xattr infra already frozen?
If this breaks anything, we can avoid that by not touching addr3 at all.
And instead keep "__u64 __pad2[1]" and "__u8 cmd[0]" in the union.
That means 72 bytes of space, but it is enough for the new nvme struct
(nvme_uring_cmd) which is also 72 bytes.
Does this sound fine?
