On Fri, Nov 08, 2013 at 12:02:21AM -0800, Christoph Hellwig wrote: > On Thu, Nov 07, 2013 at 11:56:17PM -0800, Kent Overstreet wrote: > > So, I don't think the iov_iter stuff is the right approach for solving > > the loop issue; it's an ugly hack and after immutable biovecs we're > > pretty close to a better solution and some major cleanups too. > > All the consumers aren't limited to a block-based filesystem backing, > including loop. So we need a file-ops based approach for in-kernel > dio/aio. If you have a counter proposal please at least describe it. The core issue isn't whether the IO is going to a block based filesystem (but thanks for pointing out that that's not necessarily true!) but whether we want to work with pinned pages or not. If pinned pages are ok for everything, then bios as a common interface work - likely evolving them a bit to be more general (it's just bi_bdev and bi_sector that's actually block specific) - and IMO that would be far preferable to this abstraction layer. If OTOH we need a common interface that's also for places where we can't afford the overhead of pinning user pages - that's a different story, and maybe we do need all this infrastructure then. That's why I'm asking about the stuff you meantioned, I'm honestly not sure. What I'm working towards though is a clean separation between buffered and direct code paths, so that buffered IO can continue work with iovs and for O_DIRECT the first thing you do is fill out a bio with pinned pages and send it down to filesystem code or wherever it's going to go. That make sense? I can show you more concretely what I'm working on if you want. Or if I'm full of crap and this is useless for what you guys want I'm sure you'll let me know :) -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
