Re: PATCH - final (I hope) tidy up for generic_make_request interface

From: Neil Brown (neilb@cse.unsw.edu.au)
Date: Thu Aug 24 2000 - 00:08:26 EST


On Wednesday August 23, torvalds@transmeta.com wrote:
>
>
> On Thu, 24 Aug 2000, Neil Brown wrote:
> >
> > Well, yes, but my understanding from the comment:
> > /*
> > * Temporary solution - in 2.5 this will be done by the lowlevel
> > * driver. Create a bounce buffer if the buffer data points into
> > * high memory - keep the original buffer otherwise.
> > */
> > was that we were happy with this restriction, and that it would be
> > removed in 2.5.
>
> Note that we'll have to have some good way of handling old drivers that
> don't do this.
>
> And the best way I can come up with is to have it be done in the request
> list for such drivers.
>
> Which implies that we should not have it in the generic path, but in the
> per-queue path.
>

I'm beginning to see your point...

Maybe we should then have a "blk_queue_highmem_capable(q,flag)"
function whereby drivers can tell elevator_make_request that they
are highmem aware, and so the create_bounce will be skipped ??

> > But, if you really like, I will move create_bounce back into
> > elevator_request, and also into md_make_request (and probably into
> > rd_make_request when I submit that patch - rd doesn't need the
> > elevator algorithm at all) and resubmit.
>
> Why is it in md_make_request() at all?
>
> md_make_request() should be able to avoid the bounce buffers naturally:
> the low-level driver may use bounce-buffers, but md shouldn't need to know
> that or care. Same goes for rd_make_request() - which needs to use kmap(),
> but not actually do any bounce buffers. Or did I overlook something?

md_make_request needs it (I thought) because it accesses the data in the
buffers ... sometimes.
Particularly raid5 copies data between the buffer and the stripe
cache. Obviously this can be done with kmap (now that I have read-up
and understand kmap) instead of with create_bounce.

So, in summary:
  I was advocating the "keep it simple for now" position advocated by
  the comment, and applying the one solution to all drivers.

  You seem to be advocating a "keep it flexable" position, saying that
  any driver that registers it's own make_request_fn must be highmem
  aware now.

It is hard to argue against your position now that I understand it. I
will roll out an alternate patch shortly.

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:12 EST