On Thu, Nov 07, 2013 at 11:44:45PM -0800, Christoph Hellwig wrote: > On Thu, Nov 07, 2013 at 11:39:59PM -0800, Kent Overstreet wrote: > > On Thu, Nov 07, 2013 at 11:33:24PM -0800, Christoph Hellwig wrote: > > > The changes for direct I/O from kernel space have been in for a long > > > time, and they are blocking multiple consumers of the interface from > > > getting submitted for about a year now. Even if the guts of the > > > direct-io code will get a write based on another patchset from Kent > > > that will go on top of the immutable iovec changes we need the > > > interfaces now and not another year down the road. > > > > What else is blocked on this patch series? Honest question. > > > From me alone: > Support for ecryptfs to not double cache. > AIO support for target_core_file. > > To replace code in staging: > Removal of the lustre-specific loop driver. > > And I remember others claiming to want to submit bits, too. 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. I don't know about ecryptfs and AIO for target, though - are there patches for those you could point me at so I can have a look? I can believe the iov_iter stuff is necessary for those, but I'd like to convince myself there isn't a cleaner solution. Regardless, I don't want to be blocking anyone else's work; if we do want the iov_iter stuff in now (I'm not arguing one way or the other till I look at the issues you pointed out) I can write a small patch to correctly merge with immutable bvecs; I looked at it today and it's pretty straightforward (if somewhat ugly). -- 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
