On Wed, 2005-02-16 at 13:38 -0800, Badari Pulavarty wrote: > On Wed, 2005-02-16 at 11:43, Dave Kleikamp wrote: > > 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. > > Okay, that will work. Basically, you plan to call mpage_writepages() > with NULL as get_block(). Isn't it ?
Yes > > > > 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. > > This goes back to original question, is there a point in creating > new interfaces for writepage & writepages which doesn't assuming > page->private. So far, only users are ext2+nobh and JFS. But both > of them will not use page->private for anything else other than > bufferheads (if at all used). For both of these, the mpage_writepage() > I cooked up earlier would be good enough. I agree. I just think that nobh_write_full_page() would be a more consistent name than mpage_writepage(). > I guess, we will do it ONLY if someone really needs it. Agreed ... and I don't think anyone will need it. :^) > Thanks, > Badari Thanks, Shaggy -- David Kleikamp IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
