On 9/21/22 3:26 AM, Alexander V. Buev wrote: >> ?????????! ?????? ?????? ?? ???????? ????????!? >> >> On Tue, Sep 20, 2022 at 05:46:15PM +0300, Alexander V. Buev wrote: >>> This series of patches makes possible to do direct block IO >>> with integrity payload using io uring kernel interface. >>> Userspace app can utilize new READV_PI/WRITEV_PI operation with a new >>> fields in sqe struct (pi_addr/pi_len) to provide iovec's with >>> integrity data. >> >> Is this really intended to be used exclusively for PI? Once you give use space >> access to extended metadata regions, they can use it for whatever the user >> wants, which may not be related to protection information formats. Perhaps a >> more generic suffix than "_PI" may be appropriate like _EXT or _META? > > Currently we use this code for transfer block IO with meta information > from user space to special block device driver. This meta information includes PI and some other > information that helps driver to process IO with some optimization, > special option and etc. In the near feature we can extend this info die to increased > requirements for our product. > > Also we can use this code for transfer IO with PI information from user space > to supported block devices such as nvme & scsi. > > And you are right. Just for me "_meta" is more appropriate and abstract suffix for this, > but: > > 1. "PI" is shortly > 2. "PI" and "integrity" is widely used in block layer code and I decided that > if it's called PI - everyone understands what exactly it is about. > 3. User can read/write general info only in case of using special block layer driver. > > Anyway I'm ready to rename this things. > > May be it's enough to rename only userspace visible part? > (sqe struct members & op codes) Let's please make it consistent across the userspace and internal parts in terms of naming. -- Jens Axboe
