On Sun, Apr 30, 2000 at 03:28:18PM +0100, Steve Dodd wrote:
> On Sun, Apr 30, 2000 at 01:44:50PM +0400, Roman V. Shaposhnick wrote:
>
> > Did you see my letter about readpage ? Nevertheless, I think that first
> > argument of every function from address_space_operations should be
> > "struct file *" and AFAIK this is 1) possible with the current kernel 2) will
> > simplify things a lot since it lets one to see the whole picture:
> > file->dentry->inode->pages, not the particular spot.
>
> But an address_space is (or could be) a completely generic cache. It might
> never be associated with an inode, let alone a dentry or file structure.
Ok, ok, hold on, it is filemap.c where all this stuff is defined, I guess
the name gives a hint about that it definitely is associated with some kind
of file machinery. But I understand what you mean. See my comments below.
> For example, I've got some experimental NTFS code which caches all metadata
> in the page cache using the address_space stuff. (This /mostly/ works really
> well, and makes the code a lot simpler. The only problem is
> block_read_full_page() and friends, which do:
>
> struct inode *inode = (struct inode*)page->mapping->host;
>
> At the moment I have an evil hack in place -- I'm kludging up an inode
> structure and temporarily changing mapping->host before I call
> block_read_full_page. I'd really like to see this cleaned up, though I accept
> it may not happen before 2.5.)
IMHO, you are going wrong direction here. My point is that sometimes
we would like to see address_space stuff as generic cache but it is not.
Or being more precise it is a generic cache from the generic perspective,
but when you try to use generic functions from filemap.c you are bound to
treat this beast as a file cache. I mean you can use existing infrastructure
of data, but you should provide your own methods. I am sure, that if you do
that kind of hacks you are simply using wrong interface. See for example
how nfs arranges its dir-cache ( nfs/dir.c ).
Thus my opinion is that address_space_operations should remain
file-oriented ( and if there are no good contras take the first argument
of "struct file *" type ). At the same time it is possible to have completely
different set of methods around the same address_space stuff, but from my
point of view this story has nothing in common with how an *existing*
file-oriented interface should work.
Thanks,
Roman.
