On Sat, Oct 13, 2012 at 11:48:10AM -0400, Christoph Hellwig wrote: > On Sat, Oct 13, 2012 at 08:51:28AM +0100, Al Viro wrote: > > It's somewhat pointless on its own... If you were doing something with > > the callers afterwards - sure, it would be make sense, but as it is... > > I'd really like to see ->truncate and vmtruncate done, so from that side > I'm absolutely in favour of this series. What I'm a bit concerned about > is that it just does the trivial 1:1 conversion and not actually > converts the sequence of operations to the proper form, which was one > of the two big reasons of moving away from ->truncate to start with. > > I'd love to see the full conversion, but without adequate test coverage > for all the fringe filesystems that might be a bit too much to expect > from Marco. > > I think just doing the easy conversions he did, and putting a TODO > comment explaining how it should be taken further at each of the sites > would be valueable on its own. 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... -- 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
