On Thu, Mar 20, 2014 at 09:30:41PM -0700, Darrick J. Wong wrote:
> This RFC provides a rough implementation of a mechanism to allow
> userspace to attach protection information (e.g. T10 DIF) data to a
> disk write and to receive the information alongside a disk read. The
> interface is an extension to the AIO interface: two new commands
> (IOCB_CMD_P{READ,WRITE}VM) are provided. The last struct iovec in the
> arg list is interpreted to point to a buffer containing a header,
> followed by the the PI data.
Instead of adding commands that indicate that the final element is a
magical pi buffer, why not expand the iocb?
In the user iocb, a bit in aio_flags could indicate that aio_reserved2
is a pointer to an extension of the iocb. In that extension could be a
full iov *, nr_segs for PI data.
You'd then translate that into a bigger kernel kiocb with a specific
pointer to PI data rather than having to bubble the tests for this magic
final iovec down through the kernel.
+ if (iocb->ki_flags & KIOCB_USE_PI) {
+ nr_segs--;
+ pi_iov = (struct iovec *)(iov + nr_segs);
+ }
I suggest this because there's already pressure to extend the iocb.
Folks want io priority inputs, completion time outputs, etc.
It's a much cleaner way to extend the interface without an explosion of
command enums that are really combinations of per-io arguments that are
present or not.
And heck, on the sync rw syscall side, add variant that have a pointer
to this same extension struct. There's nothing inherently aio specific
about having lots more per-io inputs and outputs.
- z
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>