From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kent Overstreet Subject: Re: linux-next: manual merge of the block tree with the tree Date: Thu, 7 Nov 2013 23:56:17 -0800 Message-ID: <20131108075617.GB17807@kmo-pixel> References: <52756583.2030808@oracle.com> <527BE7FA.90904@oracle.com> <20131107192545.GA20624@moria.home.lan> <527C2AA9.9040608@oracle.com> <20131108125307.613427c04a7527c4359e6443@canb.auug.org.au> <20131108020805.GI3842@kmo> <527C4D35.8000907@oracle.com> <20131108073324.GA31662@infradead.org> <20131108073959.GA17807@kmo-pixel> <20131108074445.GA11595@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20131108074445.GA11595@infradead.org> Sender: linux-kernel-owner@vger.kernel.org To: Christoph Hellwig Cc: Dave Kleikamp , Stephen Rothwell , Jens Axboe , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Zach Brown , Olof Johansson , Andrew Morton List-Id: linux-next.vger.kernel.org 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).