Re: [PATCH] address_space_operations unification

From: Linus Torvalds (torvalds@transmeta.com)
Date: Sun May 07 2000 - 14:26:44 EST


On Sun, 7 May 2000, Roman V. Shaposhnick wrote:
>
> Thus in my *very* humble opinion there was a problem -- pagecache should be
> generic while it is not.

I like to think of it as "there is a small subset of the page cache
functionality that is truly generic, but most ofit is very much geared
towards giving the internal Linux semantics for IO".

> Linus, please keep in mind, that I do not want to advocate the particular
> patch. All I want is simple and rational solution for my problems. Thus if
> for some reason you do not want to tackle with pagecache generalization than
> would you accept a temporary solution that changes 'readpage' to something
> like that:
> int (*readpage)(struct file *, struct page *);
> and leaves all other things intact ?

Yes. grepping for "readpage" shows that currently we already always
either:
 - pass in "NULL", or
 - pass in "filp->f_dentry".

So passing in dentry looks to be a bad idea actually: most filesystems do
not need that field at all (so we do the extra pointer dereference at call
time for no good reason), and the filesystems that _do_ want to have the
dentry would really prefer "file" anyway.

So the one case that passes in NULL would continue to pass in NULL; which
is fine as it is block-file-oriented anyway.

Hmm.. I thought we did the NULL thing for "writepage" too, but it seems
that we will actually do the swapout() with a known file every time. I'd
like to change that some day: we should be able to mark the page dirty in
"struct page", and then rely on shrink_mmap() to be able to write out a
page without even knowing who dirtied it.

So we don't actually seem to do that yet, but I think we will want to at
some point. Not 2.4.x, though.

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:21 EST