On Wed, Jul 26, 2006 at 11:13:56AM +0100, Christoph Hellwig ([email protected]) wrote:
> On Wed, Jul 26, 2006 at 02:08:49PM +0400, Evgeniy Polyakov wrote:
> > On Wed, Jul 26, 2006 at 11:00:13AM +0100, Christoph Hellwig ([email protected]) wrote:
> > > > struct address_space_operations ext2_aops = {
> > > > + .get_block = ext2_get_block,
> > >
> > > No way in hell. For whatever you do please provide a interface at
> > > the readpage/writepage/sendfile/etc abstraction layer. get_block is
> > > nothing that can be exposed to the common code.
> >
> > Compare this with sync read methods - all they do is exactly the same
> > operations with low-level blocks, which are combined into nice exported
> > function, so there is _no_ readpage layer - it calls only one function
> > which works with blocks.
>
> No. The abtraction layer there is ->readpage(s). _A_ common implementation
> works with a get_block callback from the filesystem, but there are various
> others. We've been there before, up to mid-2.3.x we had a get_block inode
> operation and we got rid of it because it is the wrong abstraction.
Well, kevent can work not from it's own, but with common implementation,
which works with get_block(). No problem here.
> > So it is not a technical problem, but political one.
>
> It's a technical problem, and it's called get you abstractions right. And
> ontop of that a political one and that's called get your abstraction coherent.
> If you managed to argue all of us into accept that get_block is the right
> abstraction (and as I mentioned above that's technically not true) you'd
> still have the burden to update everything to use the same abstraction.
Christoph, I completely understand your point of view.
There is absolutely no technical problem to create common async implementation,
and place it where existing sync lives and call from readpage() level.
It just requires to allow to change BIO callbacks instead of default
one, and (probably) event sync readpage can be used.
--
Evgeniy Polyakov
-
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]
