On Wed, 2005-02-16 at 11:28 -0800, Badari Pulavarty wrote:

On Wed, 2005-02-16 at 11:09, Dave Kleikamp wrote:

quoted

On Wed, 2005-02-16 at 10:37 -0800, Badari Pulavarty wrote:

quoted

Yes. page->private is assumed for the bufferhead usage. Do you really
need for handling page->private for non-bufferhead usage ?

For what it's worth, I'm working on some changes to jfs that will use
page->private for non-bufferhead usage for metadata, but I won't be
using a generic writepage, so it's not an issue for me.

Nope. it would be an issue for you, since jfs uses mpage_writepages()
which uses the same code - which thinks page->private as bufferhead.

The patch I am working on will call mpage_writepages() for metadata, but
will use my own writepage() rather than mpage_writepage(), and nothing
in mpage_writepages() will use page->private.

For normal data, page->private, if used at all, will be bufferheads.

quoted

mpage.c already assumes page->private implies bufferheads, so it's not
completely generic.  Would implementing this as nobh_write_full_page, to
complement block_write_full_page, make sense?

I guess, it can be done. So to really deal with this, we need to come
up with generic writepage/writepages interfaces which doesn't deal
with bufferheads.

I'm not sure how useful that would be.  Are there any users of a
non-bufferhead page->private that want to call a generic writepage(s)?
In other words, if a generic function is sufficient, you probably
wouldn't be using page->private anyway.
-- 
David Kleikamp
IBM Linux Technology Center



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click