Messages in this thread | | | Date | Thu, 13 Jan 2000 13:41:33 -0800 (PST) | From | "Daniel R. Kegel" <> | Subject | Re: sendfile and aio_write: a match made in heaven? |
| |
Ananth Ananthanarayanan wrote: > > The aio_write interface could be extended [to handle sendfile] > > by adding two new fields to struct aiocb: > > int aio_filedes2; > > off_t aio_offset2; > > These would only be checked if the aio_buf field were NULL, > > in which case aio_write would cause bytes to be transferred > > from aio_filedes2 to aio_filedes1. > > The idea of extending aio_*() to include sendfile() is good, > but I'm not sure you'd want to do that with aio_write(), or > for that matter extend aiocb with extra fields. ... > Instead, may I suggest aio_sendfile(aiocb, int outfd, int outoffset), > where aiocb defines the "input" & the outfd/offset define the "output". > We need an aiocb to support aio_error(), aio_return(), > aio_suspend(), etc ... to provide a handle to the request in progress.
Defining aio_sendfile() would solve the immediate problem, but doing it that way would not allow invoking sendfile() from lio_listio(). Sure, you could define an AIO_SENDFILE value for the aio_lio_opcode field of the aiocb structure, but unless you extend aiocb as I suggested, there's nothing for that opcode to work with.
I'm not saying a lot of people (or anyone) uses lio_listio(), but it's part of the Single Unix Standard (see http://www.opengroup.org/onlinepubs/007908799/xsh/lio_listio.html) and if we want our asynch sendfile stuff to fit into SUS someday, we'd better not adopt an interface that would make that impossible.
To answer your concern about defining a special meaning for aio_buf being NULL, I'm happy with defining aio_sendfile(struct aiocb *aiocbp), but let's add the two fields I suggested rather than adding arguments; aio_ calls generally have just one argument, and aio_sendfile shouldn't be an exception. - Dan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |