Re: [3/4] kevent: AIO, aio_sendfile() implementation.

On Wed, Jul 26, 2006 at 11:13:56AM +0100, Christoph Hellwig (hch@xxxxxxxxxxxxx) 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 (hch@xxxxxxxxxxxxx) 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [3/4] kevent: AIO, aio_sendfile() implementation.
    ... Compare this with sync read methods - all they do is exactly the same ... operations with low-level blocks, which are combined into nice exported ... It's a technical problem, and it's called get you abstractions right. ... ontop of that a political one and that's called get your abstraction coherent. ...
    (Linux-Kernel)
  • Re: Why should -1 multiplied by -1 be plus 1 and not -1
    ... >> are from an abstraction. ... >> Frege provided an explanation of what natural numbers are. ... by an abstraction principle. ... That thing they have in common is Beauty. ...
    (sci.logic)
  • Re: aio is unlikely
    ... common than sync IO. ... likelyis implemented in the kernel as a 99-100% chance of success, and unlikelyis implemented as a 0-1% chance of success. ... I would /guess/ that the effect of repeatedly hitting an unlikelywould be mitigated by smarter branch prediction. ...
    (Linux-Kernel)
  • Re: Which version control
    ... The shared code is frozen because Product A is in a release cycle? ... The common code is going to be ... share that common folder into every project needing it. ... The code stays in sync because you have the VCS. ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: Hawkins ideas on building AIs
    ... > I'm not quite sure why you say abstraction is the only way to predict ... > the common features are what's important. ... process,- discovery of common features. ... range*precision of the commonality, what I call accumulated match, ...
    (sci.cognitive)
Loading