On Tue, May 09, 2006 at 04:57:42PM -0700, Badari Pulavarty wrote:
> > > we can get the followup patch done within the next week or two so we can
> > > get it all tested at the same time. Although from your description it
> > > doesn't sound like it'll be completely trivial...
> >
> > That patch is lots of tirival and boring work. If anyone wants to beat
> > me to it:
>
> Well, I am not sure if you mean *exactly* this..
>
> So far, I have this. I really don't like the idea of
> adding .aio_read/.aio_write methods for the filesystems who currently
> don't have one (so we can force their .read/.write to do_sync_*()).
Why don't you like this idea? It helps to sort out callers into two
categories. The following is a something I wrote up to put into
Documentation/ somewhere once these patches are in.
-------- snip --------
There are two ways to implement read/write for filesystems and drivers:
The simple way is to implement the read and write methods. Normal
synchronous, single buffer requests are handed directly to the driver in
this case. Vectored requests are emulated using a loop in the higher
level code. AIO requests are silently performed synchronous.
This method is normally used for character drivers and synthetic
filesystems.
The advanced method is to implement the aio_read and aio_write methods.
These allow the request to be done asynchronously and submit multiple
IO vectores in parallel. A page cache based filesystem gets this
functionality by freee by using the routines from filemap.c - in fact
there is not easy way to use the generic page cache code without
implementing aio_read and aio_write. The other big user of this
interface are sockets. Very few character driver need this complexity.
-------- snip --------
> Is there a way to fix callers of .read/.write() methods to use
> something like do_sync_read/write - that way we can take out
> .read/.write completely ?
The only way to fix this is to add some kernel_read/kernel_write helpers
that factor out the use aio_read / aio_write if present and wait for
I/O completion logic from vfs_read/vfs_write. I started on that but it
got very messy.
> Anyway, here it is compiled but untested.. I think I can clean up
> more in filemap.c (after reading through your suggestions). Please
> let me know, if I am on wrong path ...
Currently I don't have time to actually apply the patchlkit and look at
the result, so I'll defer further comments. Beside maybe not doing all
possible cleanups (e.g. I still see generic_file_write_nolock) this
patch looks very good.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
