In message <[EMAIL PROTECTED]>, "Roman V. Shaposhnick" writes:
> 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.
[...]
> 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.
If you look at how various address_space ops are called, you'll see enough
evidence of an attempt to make this interface both a file-based interface
and a generic cache one (well, at least as far as I understood the code):
(1) generic_file_write (mm/filemap.c) can call ->commit_write with a normal
non-NULL file.
(2) block_symlink (fs/buffer.c) calls ->commit_write with NULL for the file
arg.
So perhaps to satisfy the various needs, all address_space ops should be
passed a struct file which may be NULL; the individual f/s will have to
check for it being NULL and deal with it. (My stacking code already treats
commit_write this way.)
Erez.
