lkml.org 
[lkml]   [2015]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2 1/4] aio: add aio_kernel_() interface
From
On Sun, Jan 25, 2015 at 9:31 PM, Christoph Hellwig <hch@infradead.org> 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);
>> +}
>> +EXPORT_SYMBOL_GPL(aio_kernel_free);
>
> Both functions don't actually seem to be used in this patch set.

My fault, and it is just v2 which stops using them.

>> +void aio_kernel_init_rw(struct kiocb *iocb, struct file *filp,
>> + size_t nr, loff_t off,
>> + void (*complete)(u64 user_data, long res),
>> + u64 user_data)
>
>> +int aio_kernel_submit(struct kiocb *iocb, bool is_write,
>> + struct iov_iter *iter)
>
> 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/complete/ki_ctx can be
set during initialization.

> n the second, and the count in the first seems rather confusing as
> we shouldn't even need both for a high level API. Also the private
> data should really be a void pointer for the kernel, or simply be
> left away as we can assume the iocb is embedded into a caller
> data structure and container_of can be used to find that structure.

Either one is OK.

> 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,
> struct iov_iter *iter, loff_t off,
> void (*complete)(struct kiocb *iocb, long res));
> int aio_kernel_write(struct kiocb *iocb, struct file *file,
> struct iov_iter *iter, loff_t off,
> void (*complete)(struct kiocb *iocb, long res));

It is like style of sync APIs, looks submit/complete is common
for async APIs, like io_submit().

>> + if (WARN_ON(!is_kernel_kiocb(iocb) || !iocb->ki_obj.complete
>> + || !iocb->ki_filp || !(iter->type & ITER_BVEC)))
>
> Why do you want to limit what the iov_iter can contain? iovec based
> ones seem very useful, and athough I can come up with a use case
> for vectors pointing to userspace address I can't see anything that
> speaks against allowing them either.
> call this from drivers deadling

Yes, we should allow KVEC at least.


Thanks,
Ming Lei


\
 
 \ /
  Last update: 2015-01-26 17:41    [W:0.062 / U:1.824 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site