From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [git pull] vfs pile 3 Date: Sat, 13 Oct 2012 12:04:55 -0400 Message-ID: <20121013160455.GA32420@infradead.org> References: <20121013002003.GL2616@ZenIV.linux.org.uk> <5079164D.4030307@gmail.com> <20121013075128.GQ2616@ZenIV.linux.org.uk> <20121013154810.GA9678@infradead.org> <20121013160115.GS2616@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , Marco Stornelli , Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: Al Viro Return-path: Content-Disposition: inline In-Reply-To: <20121013160115.GS2616@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sat, Oct 13, 2012 at 05:01:15PM +0100, Al Viro wrote: > You know, I'm in the middle of dealing with one such TODO. Yours, as it > were. From six years ago. kernel_thread() unexporting. TODO comments > of any form are routinely shat upon and ignored, especially when shuffled > away into less read parts of the tree... ;-/ > > I'd rather see it done fs-by-fs. Starting with something reasonably easy > to test - minixfs would do nicely. Don't get me wrong - I'm all for > burying ->truncate(); what I'm worried about is that we'll end up burying > the warning about the reasons why vmtruncate() was a bad idea, leaving the > functionality exactly as it used to be... As mentioned I agree with the concern in principle. Let's start by taking Marco's patches for filesystems that use vmtruncate but don't actually implement ->truncate. There's a few I remember offhand, e.g. procfs and ufs right now. Then we can do the actual work required ones piece by piece.