Re: [RFC] iovec in ->aio_read/->aio_write

[Benjamin LaHaise]

On Tue, Oct 15, 2002 at 11:51:21PM -0700, Janet Morgan wrote:
> - two new opcodes (IOCB_CMD_PREADV and IOCB_CMD_PWRITEV)
> - a field to the iocb for the user vector
> - aio_readv/writev methods to the file_operations structure
> - routine aio.c/io_readv_writev, which borrows heavily from do_readv_writev. 

A few comments about the interface to userland: don't add fields to the 
iocb, that breaks the abi.  Also, the iovec should be pointed to by 
iocb->aio_buf, with aio_nbytes containing the length of the iovec (that 
avoids the need for an additional field).  The structure of the iovec 
itself should probably match the iovec struct, but that means we'll need 
different opcodes for the 32 bit and 64 bit variants.  Alternatively a 
new iovec that is the same on both (like the iocb) could be defined, but 
that would be inconvenient for userland.

Within the kernel, the loff_t *pos shouldn't be a pointer -- I'm trying to 
get rid of extraneous pointers as that means an additional chunk of memory 
has to be held over the entirety of the aio request.  Similarly, the iovec 
passed into the operation itself can never be allocated on the stack.  This 
probably works for direct io where the iovec gets translated into a scatter 
gather list of pages, but wouldn't work for something like networking where 
the iovec itself gets used to determine where in the user address space to 
copy data (as this can occur after the submit operation has returned).

Aside from those details, I guess if people really need vectored ios it's 
okay.

		-ben