Keith,
>> diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
>> index aac9a4f8fa9a..38f0d6b10eaf 100644
>> --- a/include/uapi/linux/io_uring.h
>> +++ b/include/uapi/linux/io_uring.h
>> @@ -98,6 +98,10 @@ struct io_uring_sqe {
>> __u64 addr3;
>> __u64 __pad2[1];
>> };
>> + struct {
>> + __u64 attr_ptr; /* pointer to attribute information */
>> + __u64 attr_type_mask; /* bit mask of attributes */
>> + };
>
> I can't say I'm a fan of how this turned out. I'm merging up the write
> hint stuff, and these new fields occupy where that 16-bit value was
> initially going. Okay, so I guess I need to just add a new attribute
> flag? That might work if I am only appending exactly one extra attribute
> per SQE, but what if I need both PI and Write Hint? Do the attributes
> need to appear in a strict order?
We'll definitely need to be able to include multiple attributes.
Not sure how the attr_type_mask was intended to work. I guess parsing
attributes based on bit position in the mask would be one option.
The SCSI approach would be for each attribute to have a 4-byte header
with a type and a length so multiple attributes can be described by a
single buffer.
FWIW, I wasn't initially a big fan of having the attrs stored outside of
the sqe but it actually made things a lot cleaner for my use case.
--
Martin K. Petersen Oracle Linux Engineering
