On Tue, Jan 27, 2015 at 12:18:23AM +0800, Ming Lei wrote:
> > Why do we keep these two separate? Especially having the iov passed
>
> No special meaning, just follow previous patches, :-)
>
> But one benefit is that we can separate the one-shot
> initialization from submit, at least filep/comple
On Tue, Jan 27, 2015 at 1:00 AM, Christoph Hellwig wrote:
> On Tue, Jan 27, 2015 at 12:18:23AM +0800, Ming Lei wrote:
>> > Also it might make sense to just offer aio_kernel_read/write intefaces
>> > instead of the common submit wrapper, as that's much closer to other
>> > kernel APIs, e.g.
>> >
>>
On Tue, Jan 27, 2015 at 12:18:23AM +0800, Ming Lei wrote:
> > Also it might make sense to just offer aio_kernel_read/write intefaces
> > instead of the common submit wrapper, as that's much closer to other
> > kernel APIs, e.g.
> >
> > int aio_kernel_read(struct kiocb *iocb, struct file *file,
> >
On Sun, Jan 25, 2015 at 9:31 PM, Christoph Hellwig wrote:
>> +struct kiocb *aio_kernel_alloc(gfp_t gfp)
>> +{
>> + return kzalloc(sizeof(struct kiocb), gfp);
>> +}
>> +EXPORT_SYMBOL_GPL(aio_kernel_alloc);
>> +
>> +void aio_kernel_free(struct kiocb *iocb)
>> +{
>> + kfree(iocb);
>> +}
>> +E
> +struct kiocb *aio_kernel_alloc(gfp_t gfp)
> +{
> + return kzalloc(sizeof(struct kiocb), gfp);
> +}
> +EXPORT_SYMBOL_GPL(aio_kernel_alloc);
> +
> +void aio_kernel_free(struct kiocb *iocb)
> +{
> + kfree(iocb);
> +}
> +EXPORT_SYMBOL_GPL(aio_kernel_free);
Both functions don't actually seem
From: Dave Kleikamp
This adds an interface that lets kernel callers submit aio iocbs without
going through the user space syscalls. This lets kernel callers avoid
the management limits and overhead of the context. It will also let us
integrate aio operations with other kernel apis that the user
6 matches
Mail list logo
