(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 - 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
