From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: fscache review comments, part 3 Date: Sat, 7 Oct 2006 22:05:22 +0100 Message-ID: <20061007210522.GB17717@infradead.org> References: <20060928164547.GC3497@infradead.org> <8798.1160141154@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , akpm@osdl.org, linux-fsdevel@vger.kernel.org Return-path: Received: from pentafluge.infradead.org ([213.146.154.40]:28848 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S932859AbWJGVF0 (ORCPT ); Sat, 7 Oct 2006 17:05:26 -0400 To: David Howells Content-Disposition: inline In-Reply-To: <8798.1160141154@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Oct 06, 2006 at 02:25:54PM +0100, David Howells wrote: > Christoph Hellwig wrote: > > > - generic_file_buffered_write_one_kernel_page seems generally fine, but > > you must not call this directly from cachefiles but rather go through > > a file operation for it. > > I can't do that for one very good reason: you insisted that I take out[*] all > the provision of a struct file * for doing I/O to the cache, and without that > I can't call file ops. You can't have it both ways. Sorry. A file operation doesn't actually have to take a file struct, they're also available from the inode. But in some way you are right, doing that as the file_operations level without a struct file is indeed rather odd. The important point here is that we definitly need one of the operation vectors to go through instead of a direct call. I'm rather tired of all this arguing here, so if the higher gods think we absolutely need cachefs now just add a method somewhere with the signature of your function and hopefull someone will clean up the utter mess later. It's not like our current set of read/write methods makes any sense.