On Mon, May 01, 2000 at 01:41:43AM +0400, Roman V. Shaposhnick wrote:
> On Sun, Apr 30, 2000 at 03:28:18PM +0100, Steve Dodd wrote:
> > 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.
OK, more precisely, an address_space could (and IMO *should*) be a generic
/page/ cache. Anything that's caching multiple pages of data indexed by an
offset could use it. Then the page cache can sync pages, steal pages, etc.,
etc., without having to know what the pages are being used for. At the moment,
it's only used for inode data pages, but with some small changes it can be
much more useful - and I believe this was Al's original intention.
>
> > For example, I've got some experimental NTFS code which caches all metadata
> > in the page cache using the address_space stuff.
[..]
> 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.
I disagree; at the moment the interface is not generic, but my belief is
that it can be made so with only small changes to existing code. However,
I haven't looked at all existing code yet. NFS is doing something odd, and I
also should look at your code if that's possible (is it available somewhere?)
> 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.
The page cache at the moment is mostly used for caching inode data, hence
the name "filemap.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.
Hmm. Take ->readpage() for example. It is used to fill a page which "belongs"
to an object. That object is referenced in page->mapping->host. For inode
data, the host is the inode structure. When should readpage() ever need to
see anything other than the object to which the pages belong? It doesn't make
sense (to me). If you think you need to access other data, it should either
be accessible through the host object, or you have used the wrong host object.
Inode data pages are per-inode, not per-dentry or per-file-struct.
