In message <[EMAIL PROTECTED]>, "Roman V. Shaposhnick" writes:
> On Sun, Apr 30, 2000 at 04:46:37AM -0400, Erez Zadok wrote:

> > Background: my stacking code for linux is minimal.  I only stack on
> > things I absolutely have to.  By "stack on" I mean that I save a
> > link/pointer to a lower-level object in the private data field of an
> > upper-level object.  I do so for struct file, inode, dentry, etc.  But I
> > do NOT stack on pages.  Doing so would complicate stacking considerably.
> > So far I was able to avoid this b/c every function that deals with pages
> > also passes a struct file/dentry to it so I can find the correct lower
> > page.
> > 
> > The new method, sync_page() is only passed a struct page.  So I cannot
> > stack on it!  If I have to stack on it, I'll have to either
> 
>  If inode will be enough for you than ( as it is implemented in
> nfs_sync_page ) you can do something like:
>    struct inode    *inode = (struct inode *)page->mapping->host;

Yes I can probably do that.  I can get the inode, from it I can get the
lower level inode since I stack on inodes.  Then I can call grab_cache_page
on the i_mapping of the lower inode and given this page's index.  I'll give
this idea a try.  Thanks.

> > (2) change the kernel so that every instance of sync_page is passed the
> > corresponding struct file.  This isn't pretty either.
> > 
>    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.

Yes, I saw your post.  I agree.  I'm all for common-looking APIs.

> Roman.

Erez.

Reply via email to