On Wed, 13 Sep 2000, Daniel Phillips wrote:
> Alexander Viro wrote:
> >
> > On Tue, 12 Sep 2000, Daniel Phillips wrote:
> > >
> > > There is a very heavy investment in generic_read/write/mmap - I don't
> > > want to throw that away. This is a mod to Ext2, and Ext2 uses these
> >
> > Oh, but these functions don't need to be modified. Change
> > address_space_operations and they will be happy.
>
> I've been doing that all along and it works fine... but only for
> generic_file_write, not for generic_file_mmap.
?
If your ->readpage() and ->writepage() are working for the last page...
What's the problem? You don't have to implement your writepage() as a call
of block_write_full_page(). It just happens to work for UNIX-like and
no-holes sorts of layout, but there is no reason to do the same thing
in your case. You probably will find __block_write_full_page() useful
for handling the case of non-tail pages, but that's about it.
BTW, before you start exporting the stuff left, right and center - let's
see how will fs/buffer.c + your helper functions + stuff needed for
fragments look like. I suspect that we will be able to come up with better
factorization that way.
> > > library functions heavily. (As you know, because I think you wrote
> >
> > Didn't. They were around since long and the last non-trivial
> > rewrite was done by Ingo. I've changed them to use address_space_operations,
> > but impact on the mm/filemap.c was not that serious.
>
> OK, it is the use of the address_space operations that allows Ext2 to
> use generic_write wheree before it could only use generic_read and
> generic_mmap (bmap functionality). This address_space work I
> attributed to you and I would not call it trivial.
Prior to that switch ext2 was using generic_file_write() just
fine, it only had to pass a callback there. Check e.g. 2.3.9 and you'll
see. Yes, address_space_operations simplified that part, but it was more
along the lines "WTF do we have to keep readpage and writepage in
inode_operations, pass write_partial_page as callback and have a living
horror every time when we don't want copy_from_user() as a data source?"
> > Yep. So make your truncate() (expanding one - there's hardly a
> > reason to do it when you shrink stuff) do grab_cache_page() followed by
> > ->prepare_write(NULL,page,new_offset,new_offset) and you are done - it's
> > not a special case anymore.
>
> Prepare_write does a lot of stuff associated with actual I/O. I don't
> need to start a write here, or a read - just get the data onto the
> page with the buffers in a consistent state and let ext2_get_block
Yes, you do. Think of the case when your data partially covers some block.
->prepare_write() is just that:
Do everything that must be done before copying the data into page.
If your page is the tail one - well, you need different things done, but
write() still fits the "prepare + copy_from_user() + let it roll" pattern.
So make the first part your ->prepare_write() and the last one -
->commit_write() and be done with that.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
