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/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:24 EST