12/13/2012 11:43 PM, Zach Brown пишет:
(I'm jumping in mid-thread, I don't *really* know the context.)
In the other words, if it's sync, it's enough to wake up someone in
kernel (who called wait_on_sync_kiocb()) and return. Otherwise,
aio_complete() performs some steps to wake up user (who called
io_getevents()). What we need for fuse is another binary attribute:
iocb was generated by libaio vs. read(2)/write(2). Then we could use
aio_complete() and wait_on_sync_kiocb() for any iocb which was not
generated by libaio. E.g. to process sync dio in async way, we'd
allocate iocb in fuse_direct_IO on stack (as you suggested), but
initialize it as async iocb and pass it to __fuse_direct_read/write,
then call wait_on_sync_kiocb(), not to return -EIOCBQUEUED.
It sounds like you might be interested in the aio in-kernel interface
that is being worked on in a patch series that gets loop issuing aio
instead of doing sync io.
http://thread.gmane.org/gmane.linux.file-systems/69326/focus=1398723
Thanks, Zach! I've already considered using this patch, but thank you
anyway.
Maxim
- z
--
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