[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <30839.1176406991@redhat.com>
Date: Thu, 12 Apr 2007 20:43:11 +0100
From: David Howells <dhowells@...hat.com>
To: "Nate Diller" <nate.diller@...il.com>
Cc: "Andrew Morton" <akpm@...l.org>,
"Alexander Viro" <viro@...iv.linux.org.uk>,
"Christoph Hellwig" <hch@...radead.org>,
"Roman Zippel" <zippel@...ux-m68k.org>,
"Mikulas Patocka" <mikulas@...ax.karlin.mff.cuni.cz>,
"David Woodhouse" <dwmw2@...radead.org>,
"Dave Kleikamp" <shaggy@...tin.ibm.com>,
"Anton Altaparmakov" <aia21@...tab.net>,
"Evgeniy Dushistov" <dushistov@...l.ru>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
reiserfs-dev@...esys.com
Subject: Re: [PATCH 3/17] afs: convert afs_dir_get_page to read_kmap_page
Nate Diller <nate.diller@...il.com> wrote:
> but that's a lot of code to avoid a single stack allocation. The
> whole fake file pointer thing still strikes me as a little ugly, and
> you're definitely not the first one who needed this sort of hackery.
> ugh
A better way might be to stick a void * in struct file and pass that through
to readpage() and readpages() instead of the struct file *. That way, anyone
who wants the traditional arrangement can just point that extra void * at the
struct file.
Of course, I'm in favour of making it a struct key * like this:
struct address_space_operations {
...
int (*readpage)(struct key *, struct page *);
...
int (*readpages)(struct key *, struct address_space *,
struct list_head *, unsigned);
...
};
struct file {
...
struct key *f_key;
};
struct page *filemap_nopage(struct vm_area_struct *area, ...)
{
...
struct file *file = area->vm_file;
...
error = mapping->a_ops->readpage(file->f_key, page);
...
}
But I'm not sure the NFS crew, for instance, would be happy with that. Maybe
passing file->private_data through would do. That's basically what NFS and
FUSE, for instance, want, and it would also do for AFS.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists