> +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.
> +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
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.
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));
> + 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
